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This is a continuation of U.S. Provisional Patent Application Serial No. 
60/133.401, filed May 10, 1999, the disclosure of which is hereby incorporated herein 
by reference and on which priority is hereby claimed. 

A DISTRIBUTED SYSTEM TO INTELLIGENTLY ESTABLISH SESSIONS 
BETWEEN ANONYMOUS USERS OVER VARIOUS NETWORKS 

FIELD OF THE INVENTION 

This invention is related to a system and corresponding method of establishing 
communication sessions) between users as a function of their availability and/or 
communication device(s). 

BACKGROUND OF THE INVENTION 
Typically, users of communication tools (e.g., mobile phone, PCs, email, etc.) are 
faced with two essential tasks: locating the device address of other users to 
communicate with, and establisliing a communication session with that device. These 
tasks typically differ depending upon what device the user(s) is/are using. For example, 
on a mobile phone with messaging capabilities, users usually locate other users by 
Finding them in their local address book, and then establish either a voice session with 
that user by dialing a phone the user's phone number, or they may type in a short text 
message (STM) and send that to the other user, either to their mobile phone or their 
email. Depending on the phone operator of the callee, he/she may or may not be able to 
receive these calls. 

As another example, a user of a PC based text-chat software may have a list of 
other users that they can initiate a chat session with. However, they will only be able to 
do so when the other person is logged on. When logged off, they have no way of 
determining how to reach that person, nor can that person be made aware that someone 
is trying to reach them. 

Thus, problems to be solved may include any or all of the following. How to 
make contact information available and configurable centrally, independent of devices, 
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and give users a single address to use for all communications. How to advertise the 
availability of a user to participate in some kind of communication session. How to 
initiate a communication session with another user (i.e., a contact) independently of 
devices and thus without knowing any device addresses of the contact in question. How 

5 to enable users to centrally control how calls intended for them should be handled with 
or without their direct intervention. How to insure interoperability of these functions, 
when the callers and callces devices are on distinct networks, possible operated by 
different service providers. How to keep other users from changing a user's contact 
information or routing settings or in any other way impersonate another person. How to 

10 allow a user to block annoying people from contacting him/her in a central location. 
How to enable more than one organization/company/operator to provide services 
described herein in an efficient and/or interoperable way. 

The SS7 system allows intelligence in routing decisions made when setting up a 
phone call (e.g., see Intelligent Network (IN) architecture originated by Bell 

is Communications Research), in which the service logic for a call is located separately 
from the switching facilities, allowing services to be added or changed without having 
to redesign switching equipment A later version of IN called Advanced Intelligent 
Network (AIN) introduced the idea of a service independent architecture in which a 
given part of a telephone number can be interpreted differendy by different services 

20 depending on factors such as time of day, caller identity, and type of call. AIN makes it 
easy to add new services without having to install new phone equipment. 

Unified messaging systems allow users to provide essentially one address for a 
variety of communication options, typically including phone calls, voice mailbox, fax, 
and e-mails. Typically, all messages are stored in one centralized inbox, that the user 
25 can access from different devices, sometimes using media translations (e.g., converting 
text messages to voice). This effectively reduces the number of device addresses that a 
user needs to give out. There are numerous companies working with unified messaging 
products. 
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Various companies have created networks running on top of the Internet that, 
allow users to send each other short text messages and monitor the status of other users, 
where the status is usually defined as whether a user is currently connected to the 
network or not This kind of functionality is currently being considered as an IETF 
5 standard called IMPP (Instant Messaging and Presence Protocol). 

The Session Initiation Protocol (SIP) is in the process of becoming an IETF 
standard, and has been positioned as the successor of SS7 in IP based networks. The 
protocol basically allows users to invite other users to arbitrary communication sessions 
over the Internet, and at the same time allows for arbitrary routing of these invitations. 

to The aforesaid IN and AIN approaches used in SS7 are limited to the phone 

network and are not easily extendable to other networks like the Internet Thus, there is 
no easy way to advertise availability of other users to communicate. There also is no 
easy way for users to configure their routing, except through limited interfaces. Instant 
messaging systems are typically only IP based, and do not in general allow 

15 communication across different networks. Most such systems rely on users to be 

connected to the system in order for their routing to be active and they disclose network 
addresses to other users, which potentially can be considered a security breech. 
Furthermore, most systems rely on a centralized architecture which may make it 
difficult to distribute a user database and traffic among many providers. 

20 In general, various systems address a portion of the problems discussed above. 

However, there exists a need in the art for a system/network and coiresponding method 
for handling one or more of the aforesaid problems in a more comprehensive manner. 

SUMMARY OF THE INVENTION 

A system includes a loosely confederated network of server clusters along with 
25 any number of client terminals (i.e., clients) that connect to the clusters. 

Terminals/clients can be software entities running under some operating system or any 
other device running on some communication network that can have access to the 
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cluster. Users arc registered within some specific cluster and given a unique user ID. 
This user ID along with the ID of the cluster (CID) constitutes a globally unique user ID 
(UID) within the whole system. Users can be human or any other entity that connects to 
the cluster via some client terminal or by some other method/system. Terminals can 
5 gain access to any number of services running within the cluster, or to services running 
in other clusters (a "service" is a software entity that can have arbitrary functions). The 
connection between the terminal and the cluster is secure, and may use cryptography in 
certain embodiments. 

Basic services which may be provided within each cluster, include, for example: 
10 1) dynamic user properties, called online status or user's "presence 11 , that allows users 
and clients to centrally define and modify data points linked to them; these changes can 
cither be manual (explicitly made by the user) or automatic (by some client or server 
side logic); 2) contact list and contact notification, that allow users to subscribe and be 
notified of the online status of other users, and/or be notified of change of other user's 
15 presence information; and 3) routing service, that allows users to send requests (i.e., 
invitations) for communication sessions to other users, as well as configure how these 
invitations are handled depending on the user's current presence information. 

The routing service allows users to send invitations to other users to establish an 
arbitrary communication session (e.g., text chat session, voice chat session, web 

20 conference, etc.) over arbitrary networks. The requests are not sent directly between 
users. Instead, the routing service for the sending/inviting user sends the invitation to 
the routing service for the receiving user. The routing service for the receiving user 
determines, according to a logic specified by the same receiving user, how the request is 
handled and what services are available to handle the request. For example, the routing 

25 service for the receiving user may forward the invitation to the receiving user's client, 
may ignore the invitation, may forward the invitation to the receiving user's mobile 
phone, or may forward the invitation to the receiving user's inbox so that the user may 
later read the invitation. 
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The cluster and services within it make the necessary minimum setup for the 
session to be established, and thus no network addresses need to be exchanged between 
the users, thus retaining the anonymity of the users. As users can be software entities as 
well as persons, the system allows communication sessions between users and arbitrary 
5 data services. In certain embodiments, the system does not need a central database of 
all users to function, but clusters can forward requests to other clusters, and thus insure 
the connectivity of all clusters within the system. 

The application provides users with a buddy list (i.e., contact list). A user can 
add other users to this list and organize them into groups. Using the application, the 
10 user can be aware of the online status of users in his/her buddy list (i.e., contact list), 
and get notification when these users' statuses) changes. Moreover, a user can set 
his/her own online status, make himself/herself invisible to annoying users, and send 
users in his/her buddy list any kind of message with a simple double click. 

In certain embodiments, messages are not sent directly between users, but instead 
15 through at least one intermediate routing service (RS) provided on a server of one of the 
users. Thus, in certain embodiments, a user may hide or mask his/her personal 
information from other users even when communicating with them. In certain 
embodiments, a user may establish a communication session with another user without 
knowledge of the client device (e.g., PC, mobile phone, etc.) being used by the other 
20 user; as die network arranges for communication (e.g., text chat session, voice chat 
session (PC to PC, PC to PSTN, or PC to mobile phone), web conference, or pages (PC 
to PC, PC to SMS)) between the users regardless of the client device being used by the 
called user. Thus, the network enables any of the above communication services 
between users, and the initiating user need not know whether the other user is currently 
25 online via his/her PC or may instead be reached via pager or mobile phone. 
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BRIEF DESCRIPTION OF THE FIGURES 

Figure 1 is a schematic diagram of a plurality of server clusters connected 
together according to an embodiment of this invention. 

Figure 2 is a schematic diagram of an exemplary one of the clusters of figure 1 
according to an embodiment of this invention. 

Figure 3 is a functional diagram illustrating how a first user (having a client A, 
such as a PC) sends an invitation message to another user (having a client B, such as a 
PC) according to an embodiment of this invention, wherein client B's routing service 
forwards the invitation message to client B. 

Figure 4 is a functional diagram illustrating how a first user (client A) sends an 
invitation message to another user (client B) according to an embodiment of this 
invention, wherein client B's routing service forward the invitation message to client 
B's mobile phone because client B's client is not online. 

Figure 5 is a functional diagram illustrating how a first user (client A) sends an 
invitation message to another user which is a service such as a software entity according 
to an embodiment of this invention, wherein the software entity's agent or routing 
service forwards the message to the software entity so that communications can be set 
up between the first user and the software entity. 

Figure 6 is a functional diagram according to an embodiment of this invention 
illustrating that connections between users can be forwarded across clusters. 

figure 7 is a diagram of an exemplary aspect of a client as it appears on a user's 
display screen (e.g., display of a PC) according to an embodiment of this invention, 
wherein when launched the client application prompts the user for a user name, 
password and/or server address; after which the client can connect to the appropriate 
user server and establish a secure communication with it. 
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Figure 8 illustrates an exemplary contact list of a user as it appears on the user's 
terminal/client's display screen according to an embodiment of this invention. 

Figure 9 illustrates a menu list of a plurality of different types of invitation 
messages which a user may choose from to send to another user, this figure illustrating 
5 how the menu list appears on the user's terminal/client's display screen according to an 
embodiment of this invention. 

Figure 10 is a functional diagram illustrating how each operator may run one or 
more clusters according to an embodiment of this invention, where each of the clusters 
can communicate with one another so that invitations/messages/data can be sent from a 
10 user on one cluster to a user(s) on another cluster. 

Figure 1 1 is a functional diagram illustrating the server structure (e.g., 
communication links between respective servers and between servers and respective 
clients and database(s). 

Figure 12(a) is a diagram illustrating how an exemplary mapping function of 
15 Figure 1 1 works according to an embodiment of this invention. 

Figured 12(b) illustrates a user identification (UID) which is given to a user, that 
is applicable throughout the entire application or system/network, according to an 
embodiment of this invention. 

Figure 13 is a functional block diagram illustrating exemplary components of the 
20 cluster of Figure 1 1 according to an embodiment of this invention, and further 

illustrating how the cluster may communicate with other entities such as clients, other 
clusters), and/or the Internet. 

Figure 14 is a flowchart illustrating steps taken when a user sends an invitation 
message to another user according to an embodiment of this invention. 
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Figure 15 is a flowchart illustrating steps taken when a user (e.g., Carl) sets up a 
chat session with at least one other client (e.g., Anne), according to an embodiment of 
this invention. 

Figure 16 illustrates exemplary data structure^) on a user server, via the user 
service, according to an embodiment of this invention. 

Figure 17 illustrates exemplary data structures) for the contact status service on 
an exemplary connection server according to an embodiment of this invention. 

Figure 18a illustrates a data structure^) stored for the contact list service, which 
may be stored in the database and retrieved on demand, according to an embodiment of 
this invention. 

Figure 18b illustrates a data structure for user profiles according to an 
embodiment of this invention. 

Figure 19 is a schematic diagram illustrating a logon procedure or sequence for a 
user (or the user's client) according to an embodiment of this invention. 

Figure 20 is a schematic diagram illustrating a logoff procedure or sequence for a 
user (or the user's client) according to an embodiment of this invention. 

Figure 21 is a schematic diagram illustrating a contact Bl's logon/logoff 
procedure or sequence according to an embodiment of this invention, wherein a user or 
a user's client can be monitoring the contact Bl and knows when the contact comes 
online and when the contact goes logs off. 

Figure 22 is a schematic diagram illustrating steps taken during a user's or 
client's procedure of adding/removing a contact to/from the user's contact list. 

Figure 23 is a schematic diagram illustrating steps taken during a user's or 
client's procedure of adding/iemoving another user to/from the user's blinder list. 
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Figure 24 is a schcmadc diagram illustrating steps taken (i.e., a message 
sequence) when a user inverts lusher blinded user list according to an embodiment of 
this invention (the sequence is similar to the one when a user is added to a blinded list). 

Figure 25 is a chart illustrating a summation of database operations (e.g., queries 
to the database) for contact list functionality according to an embodiment of this 
invention. 

Figure 26 illustrates the position and/or functionality of an administration 
tool/service according to an embodiment of this invention. 

IYRTAT1JED DESCRIPT ION OP CERTAIN 
EXEMPLARY EMBODIMENTS OT THIS IN VENTION 

In the following description, for purposes of explanation and not limitation, 
specific details are set forth such as particular embodiment, network architectures, 
signaling flows, protocols, techniques, etc. in order to provide an understanding of the 
present invention. However, it would be apparent to those skilled in the art that the 
present invention may be practiced in other embodiments that depart from these specific 
details. In certain instances, detailed descriptions of well-known methods, interfaces, 
' devices, protocols, and signaling techniques are omitted so as to not obscure the 
description of the present invention with unnecessary detail. 

Initially, it is noted that the notations in software design diagrams comply with 
the UML standard (Unified Modeling Language) in most cases. The same notation is 
used for data diagrams as is used for class diagrams. The reader should therefore note 
whether data structures or conventional classes are being described. In high-level 
sequence diagrams, half -arrowheads are used for messages with no reply. Whole- 
arrowheads are used for a request-reply message pair in those cases where the exact 
details of the back-and-forth communications are not important 
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Familiarity with the drawings and certain terms is helpful in the context of the 
instant application. Thus, set forth below are a plurality of definitions that apply to this 
application and the patent to result therefrom. 

DEFINITIONS/GLOSSARY OF CE RTAIN TERMS USED HEREIN 
"Community." a set of users with which a user can interact through his/her 
application. There may be many different communities or there may be a single global 
community. This is defined by how servers are grouped together arid to which servers 
users connect. 

"Application." This refers to the entire system/network of this invention; 
including the client-side software, the server-side software, the data stored, and the 
functionality of this system as a whole. 

"Client" The software used to access the application from the client or user side. 

"Back-end/ 1 The set of servers, networks, and software to which a given client is 
connected, directly or indirectly (i.e. its local cluster, plus any clusters the local cluster 
is connected to). 

"Cluster/' A collection of servers plus a database, connected with a high-speed, 
reliable, secure network. The back-end is a set of interconnected clusteis. 

"Local cluster." The cluster which a given client is direcdy connected to. 

"User." An entity, human or software, that accesses the application through a 

client, 

"Framework." The application framework that is common to back-end servers. 

"Service." A service is a software entity which resides on, e.g., a server and 
provides a set of functions to clients of the server. The set of functions it provides is 
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specified by a protocol description, which defines in a non-ambiguous way how to use 
the service. 

"Service creator." A programmer that writes a service. 
"Oient implement*." A term used for programmers that create clients to the 
5 back-end system. 

"Message." A piece of information sent from one user to another. 
"Control message." A piece of information sent from a client to a server or from 
a server to a client or between servers. Control messages are used to access the 
functionality of other components of the system. 
10 "Request." A control message initiated by a client and sent to a server. 

"Reply." A control message sent from a server to a client in reply to a request. 
"Notification." A control message initiated by a server and sent to a client. 
"Response." A control message sent from a client to a server in response to a 
notification. 

l5 "Mode of communication." Tne method used for real-time communication, e.g. 

voice, herein. 

"Conversation." A dialogue between two or more users carried out in real time. 
A "message type" is the type of information sent in a message, e.g., a short text 
message. 

20 "CS." Connection Server. This can refer to the server software and/or the 

machine running it. Which is being referred to should be obvious from context 

"DB." Relational database, preferably including the machine rurming it 
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"UMF." User mapping function. This is conceptually a single entity but is 
actually implemented on each CS, US and ICS, and thus may be multiple entities. UMF 
is preferably stored in the DB, although it may be otherwise stored in other 
embodiments. 

• GRID." Group identifier for contacts in contact list. 

"CID." Cluster identifier 

"ICS." mtra-Cluster Server. Can refer to the server software and/or the machine 
mnning it Which is being referred to should be obvious from context. 

"ICSID." Intra-Cluster Server identifier 

"UID." User identifier 

"US." User Server. Can refer to the server software and/or the machine running 
it. Which is being referred to should be obvious from context 

"USID." User server identifier. 

"Message repository." An entity which can receive messages of one or more 
15 types on behalf of a user and store them at least until the user retrieves them, e.g.. a fax 
machine. 

"Device." An entity which can function as one or more conversation endpoints 
or as a message repository for one or more message types or as both. Also, a device 
may be able to send messages of one or more types. An example of this is a GSM 
20 phone, which is a short text message repository, and a conversation endpoint for voice 
conversations, 

"Profile." A set of routes where each route is enabled for a user or a group of 
nsers as defined in the buddy/contact list. A profile is complete in the sense that for 
every user there is a route for every mode of communication. 
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DESCRIPTION OF EXEMPLARY EMBODIMENTS OF THE INVENTION 

A system/network according to certain embodiments of this invention includes a 
plurality of client applications (e.g., Win32 operable by respective users) and a back- 

5 end server system having a plurality of clusters (e.g., running on Windows NT). A 
main function is to provide users with a simple and secure way of establishing arbitrary 
communication sessions with other users or services, running cither over IP networks or 
other networks, e.g., PSTN. It also provides operators (an operator is one who operates 
or manages at least one cluster) a comprehensive environment in which to deploy value 

10 added services (e.g., search engine services, database services, shopping services, 
services for sending users stock information such as stock prices, video conferencing 
services which enable user(s) to set up a video conference via a video conferencing 
server that is external to the application, etc.) to their users and to be able to charge for 
their use, as well as providing them a way to link their installed base of services over to 

15 IP networks. In basic terras, aspects of the system/network act as a broker(s), and can 
broker communication services between two or more people (or their respective 
clients/PCs/phones), as well as broker access to value added services, some 
communications based - others not. Access to the services is provided either by 
lightweight clients, running on various operating platforms or through gateways for 

20 browser based systems, such as WAP (Wireless Application Protocol). The 

system/network is designed to enable easy building and operation of Value Added 
Services (VAS), using the user management functions, security, authentication and 
charging features of the system/network as their base. Since the system/network is 
designed to offer accessibility and mobility, a user will be able to access his or her data 

25 and services from virtually any communication device - computer, mobile phone, 
handheld devices etc. ensuring a broad reach for Value-Added Services of the 
system/network. 
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Figure 1 illustrates a plurality of clusters 1 of the system/network which may 
communicate with one another, while Figure 2 illustrates an exemplary cluster 1 of the 
Fig. 1 embodiment Referring to Figure 2, a basic installation of the system/network 
includes a number of interconnected servers 3, each of them running a number of 
services 5. Such a collection of servers is called a cluster 1 as shown in Fig. 2. A 
cluster 1 defines an address space for services 5, and provides the low-level 
connectivity for services to connect to each other, as well as for connections with 
external servers. Each service can provide access to its functionality through some well 
known protocol(s), which are again built on top of a generic stream model. Thus a 
service can request another service by name, and establish a connection with it using a 
service specific protocol. 

External users 7 and their respective clients 1 1 (e.g., a user's PC, mobile phone, 
and/or PDA) can connect to services within the cluster via a special connection service, 
that typically runs on server(s) (connection servers) at the boundary of the cluster's 
firewall 9, and listens for connections on a specific port Streams established through 
that service are secure and encrypted in certain embodiments, e.g., using the SSH 2.0 
protocol in the case of a Win32 client As such, the cluster I along with all connected 
users 7 and clients 11 can form a virtual private network within which connections 
between services can be freely established. Connections can also be made between 
services and/or users 7 in different clusters 1, as illustrated in Fig. 1 . Such connections 
go through a special inter-cluster service, which can limit what services are actually 
available. Connections between clusters may also be secure and encrypted in preferred 
embodiments of this invention. 

Additional servers and software that fall outside of this architecture may also 
form an integral part of an installation®. As such they are considered part of the 
cluster, examples being a robust database(s) 13 (e.g., Oracle 8) and various operation 
and maintenance tools with which servers 3, users 7 and/or clients 1 1 may 
communicate. 
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Typically, certain servers 3 are setup with a given configuration of services, and 
these might sometimes referred by some given name, e.g., servers that run the 
connection service for external clients are called connection servers as discussed 
hereinbelow, though they do not differ architecturally from other servers. 
5 in certain embodiments of this invention, by default a cluster 1 will run a basic 

set of services. In exemplary embodiments, this basic set of services may offer the 
following features: 1) allow each user (or user's client) 7 to have a unique identity 
within all clusters; 2) provide each user 7 the ability to connect and be securely 
authenticated by thecluster 1 using mat identity; 3) provide each user 7 the ability to 
10 definearbitrarysetsofdatarelatedtothatidentity^s^ 

database 13, and this data is referred to herein as "presence" data of the user); 4) 
provide each user 7 the ability to publish a dynamic status information and/or presence 
information related to their identity (in a simple case, this status or presence might be 
whether the user is currently online on his/her PC or not); 5) provide each user 7 the 

the ability to look for other user's identity^) using queries by name or other useful 



criteria* 



Retain* to Figures 3-6. « taction of the system/network is to provide the 
» possible for osers 7 to establish arbitrary commmdeodon sessions with o*er users 7. 
Different types (e.g., voice or text) of connnnnicadon ma, be established in different 
embodiments. The system/network handle* the initial discover, of the mutual 
communiendon channel using 'Invitations." "Invitations" may also be referred to as 
invitation messages or INVlTE(s) herein, for purposes of simplicity. 
23 An invitation is basically a request from one user 7 to another to join him/her in 

some given type of communication The format of these ma, folio* the IETF srandard 
called SIP (Session Initiation Protocol), in cenain embodiments. Typically, a chen. 11 
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will support some given set of communication types and will know how to create a SIP 
invitation for each type. Whenauser? wishes to establish a communication with 
another user, he/she will invoke some function within his/her client 1 1 , requesting the 
client to send an invitation of a given type to some selected user. The user's client 11 
will then form the correct SIP message and send it to a special service within me 
cluster, called the Routing Service (RS). In certain preferred embodiments, each user 
has a particular routing service provided on the user's user server (US). 

In certain embodiments, the Routing Service (RS) is invoked in the context of 
the recipient of the message, but may or may not be invoked in the context of the 
sending user. A function of the RS is to decide what to do with the invitation message. 
As such, messages are never sent directly between users, but always from a user to 
another user's Routing Service (RS). The decision logic of the Routing Service is local 
to *e user and fcusnuybepmgr^ 

desires, and it can as complex as needed, though it will usually be limited by the 
necessity of users to be able u> control it in some simple xnanne, Whatever the logac.s, 
the Routing Service can end updoing two things: ignore the invitaaon or forward n to 
some other service that accepts invitations of the given communication type. Services 
that accept invitations are called device handlers. Clients 1 1 are exemplary types of 
device handlers in certain embodiments of this invention. 

A device handler is a communication endpoints to which the routing service can 
dispatchinvitations. Device handlers are specifically used to interface with other 
networks. For example, to dispatch text pages to the mobile cellular 
telecommunications network, a device handler is installed that accepts text pages, looks 
up the receiver' s mobile number and then sends all the relevant information to some 
, standard paging gateway, such as an SMS gateway. Alternatively, a device handler may 
enables phone calls. Currently two such device handlers are available: one that 
interfaces with the Ericsson IP Telephony system, thus making it possible for Vmce 
Chat invitations to end up in the PSTN network. Another device allows the routing of 
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text pages to the GSM network. All services and device handlers can access 
administrative information in the database, e.g., for checking user's accounts and 
permissions to use the specific service. This allows centralization of service billing in 
the database. Services can easily be created and deployed within the system using a 
service SDK. In this manner, support for routing to new networks or existing services 
can easily be added to the system. 

Referring to Fig. 3, a first user A (having a client A) desires to send an invitation 
message to user B (having client B). As an illustration of a device handler, a connected 
client 1 1 can present itself to user B's RS as being an eligible end point for invitations 
of certain types. For example, if user A sends an invitation for text chat to user B as in 
Fig. 3, and user B has his/her RS configured such that when he/she is connected to the 
cluster, all invitations should be forwarded to his/her client 1 1, user B's RS sends the 
invitation message accordingly and the invitation ends up at user's B client 1 1 for 
access by user B. In this case it is assumed that on user B's client 11, there exists some 
15 code that will accept and process this specific invitation. 

As shown in Figure 4, in other cases device handlers arc not clients 1 1 of users 
but instead are actual services 10 running (e.g-. on servers or other devices) within the 
cluster. These services 10 typically interface with some external devices or networks 12 
(e.g., telephone or other network), translating the invitation to whatever signaling 
20 protocol is adequate for that device or network 12. In Figure 4, user B has instructed 
his/her RS to forward invitation messages to his/her mobile phone 14 when user B is 
not online. Thus, user B's RS forwards the invitation message to service 10 which 
interfaces with the external cellular telecommunications network (e.g., GSM), which in 
turn enables the message to be forwarded to the network and ultimately to user B's 
mobile phone 14. In this manner, a device handler 10 might translate an invitation to an 
actual phone call to a user. 



25 
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As stated before, the invitation mechanism does not put any limitations on what 
type of communication is brokered by a Routing Service (RS). The actual types of 
communication possible are only limited by the device handlers 10 (and/or client 
devices 1 1) available to handle them, the another user so desires. The session 
negotiation does not implicidy involve the exchange of user's network addresses, such 
as IP number or phone number, in certain embodiments. The benefits of this approach 
include privacy and the fact that users do not have to worry about how to reach other 
users. Given an invitation from a user 7, the Routing Service (RS) of the called user 7 
(i.e., the callee) will decide how this invitation should be handled, without the calling 
user 7(i.e.. caller) having to know how the communications channel between the users 
was set-up or on what network. Thus, for example, a voice session might end up in the 
telephone system without the caller knowing it It is however up to the actual 
communication logic invoked whether network addresses actually end up being 
exchanged, and may be out of the control of the routing protocol and/or the application 
framework. The decision on whether user anonymity should be maintained for all 
communication types is thus up to the operator that operates a cluster in certain 
embodiments of this invention. 

As seen above, the functionality of a cluster 1 can be extended by the use of 
device handlers that are a specific type of services. They are a simple example of 
additional services that can be added to a cluster. From an architectural point of view, 
there are no limits on what kind of services can be added to a cluster given an adequate 
SDK. This opens the way for the creation of complex value added services that 
possibly interface with some corresponding client modules, offering functionality that 
goes way beyond the elementary one described above. 

Referring to Figure 5, another entry point for additional services 16 comes 
through the use of special clients 10. These are services 16 that actually use the 
client/server protocol to manifest themselves as any other user within the system. Such 
'artificial' users 16 are called agents. From a user point of view, an agent looks just like 
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any other user, Le., he/she can monitor its status and send invitations to it The 
difference is that when communication is established between a user 7 and an agent 16, 
it really is a form of interaction between the user and some software entity. The type of 
conununication might be voice or text, but more likely it would be some custom data 
5 communication between the agent and some special client software installedon the 
user's machine. This type of extensibility allows for novel and interesting services. 

As seen above, many services might offer access to chargeable resources, such as 
the phone system, a cellular telecommunications network, an online shopping network, 
or the like. This calls for a way to control the access of users 7 to these resources and a 

10 wayofmonitoringtheirusage. In certain embodiments, the system/network according 
to this invention may support the notion of account types for users, where each account 
type gives access, to some set of services. In this manner, control of service usage can 
be administered easily. For more detailed charging, each service can define its own 
billing policy and act accordingly. Some services might choose to simply log all 

15 activity, for later accounting, while others might dynamically monitor the user and their, 
current account situation, possibly terminating a session if a credit goes down to zero. 

Referring to Figure 6, as users 7 have a globally unique identity, connections 
between users can be forwarded across clusters 1 (i.e., from one cluster 1 to another 
cluster 1). This may be done via a special service. i.e., the inter-cluster service, that acts 
20 asaproxybetweenservicesindifferentclnsters. From the point of view of the services 
involved, the proxy is preferably transparent or substantially transparent. The only 
limitation is that the cluster operator can configure the inter-cluster service to only allow 
remote access to a limited set of services. Thus operator specific value added services 
can be made exclusive for a given cluster. 

25 From a user Ts perspective, a client 1 1 appears to the user as a small 

inconspicuous application, which in closed form on a user's PC appears as a small baU 
on the desktop. As shown in Hgure 7, when the user 7 launches the application, he/she 
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is prompted for his user identity, which includes die address to his operator, and a 
password to be securely authenticated. At this point, the client 11 connects to the 
corresponding server 3 and establishes a secure connection with it The connection is 
both strongly authenticated and may well as encrypted, using known state^f-the-art 
cryptographic technology, and can thus not be cracked by mischievous parties. 

If logging on is successful, the ball may open and expose a variety of functions 
and displays which may be utilized by the user/client. One such function is known as a 
contact list (e.g., Fig. 8 illustrates a portion of such a list) . This list is maintained by the 
user and may include, e.g., other individuals that the users knows and has contact with 
and optionally addresses or IDs of the other users. In certain embodiments, the list may 
show the online status of these other users. This status reflects whether a given user is 
currently logged in the system or not, thus giving information whether that user 7 is 
hnmediately reachable. Actually, users have a range of possible statuses they can 
specify, e.g., to inform other users that they are indeed online, but wish to not be 
disturbed or are temporarily unavailable. The list can easily be organized by defining 
folders, as well as choose from different display modes. The user can enter new 
contacts, either by typing in their system/network identity (user ED or UID) (if they 
know it) or by initiating a search in a directory service, where they can search according 
to various criteria, such as names, e-mail, et cetera. An exemplary UID assigned to a 
user is shown in Fig. 12(b). 

The client 11 architecture may be open via the use of anAdd-OnSDK. This 
allows developers to add new type(s) of communication modules to the client, e.g., to 
establish data communication sessions with some remote service. In this manner, the 
client can be used as a basis for more complicated applications, while still benefiting 
from the whole underlying user and security model offered by the basic client. The 
client/server protocol can also be used to create completely new type of clients, that 
allow developers to integrate services that manifest themselves as users to others. The 
security protocol preferably used by the client is SSH (Secure Shell Protocol), which is 
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generaUyconsideredoaeofthemostadvanced today. It uses the dedicated port number 
22 whichisgenerallyopeoonmostfirewalls. For communication sessions estabushed 
by add-ons, the security is up to the add-on developer and the communication protocol 

that is used. AniteWbB^^**^^ - 
inbox is cached and encrypted on the client machine, thus minimizing network traffic 
for frequent users. The client is fully localizable, and can also be co-branded for 
specific operators. 

As for senera 3, . exempt server setup according to an embodiment of mis 
invention includes , network of servers 3 and one datebase 13. Sueh a minima, sen* . 
called a cluster, and represents a small administrative structure of the system/nemo*. 
Each server3oan be configured m sun a certam cotniguration of services. Each snob 
sendee is either some integral part of me systcm/netwo* of mis invention or some 
additional service installed by the opendor. One of the basic services available la the 
eonnection and authentication service that handles client 1 1 accedes) to the cluster 1. 
This is the single point of access into the cluster from the IP network, ami the cluster 
shouldomenvisebecondderedasnmningmatrus.edorsecurel^. Byaddingm*. 
servers 3 running mi. service, me whole duster can be scaled to handle a potentially 
Renumber of simultaneous connections. Anomer se, of services are related to users 
7 and handle information requests, propagation of online stems and routing of 
invitations. Again, these functions can be scaled by adding more servers 3 running 
these services. Finally, a specific service handles connections to other clusters, thus 
allowing users from different clusters and providers to communicate. Linlong of 
servos 3 will be discussed below in more detail. 

All these services of a duster 1 may interact with the database 13. which is dm 
, reposifcryofallpetsistentdata. His includes both user specific data, service specific 
data and administrate data. THe database can be scaled, made redundant and as robust 
as um operator wishes, all depending on needs. An Oracle database may be used, but 
the system/network can be adapted to outer types of databases. Tims, incertam 
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embodiments of this invention, all this information is stored centrally on the server side 
in database 13 of the user's cluster 1, and is downloaded to the user's client 11 when the 
user 7 logs in. This makes it possible to use any installed client that is compatible with 
the system/network without preliminary customization. 

5 By selecting users from this contact list, a variety of functions become available 

to the selecting user 7. To start with, the selecting user 7 can display information about 
a given contact (e.g., a selected user from the list). This information may be a 
combination of items that the contact has actually defined for himself, e.g., preferred 
nickname and other public information. In addition, a function which becomes 

lo available to the selecting user 7 is the ability to send invitations to the selected contact 
from the list. The notion of invitation here is a very generic one, and may use an 
upcoming standard protocol called SIP (Session Initiation Protocol). As described 
earlier, an invitation may be a request sent from one user 7 to another user 7, asking the 
another user 7 to join the inviting user 7 in a communication session of a given type. As 

is a comparison, dialing the number of a person on a telephone is essentially sending an 
invitation (in the form of a telephone ring) to that person. 

There is no limitation on what kind of invitations can be sent. A sending user 7 
is provided with at least a few elementary types of invitations as well as the necessary 
logic to handle the corresponding communication sessions if they do get established 

20 Referring to Figure 9, these elementary types include the following: 1) Pages: these 
consist of short text messages (they are the most simple type of invitations, although 
they do not imply an acknowledgement from the receiving end; 2) Text Chat: these 
invitations can establish a real-time text chat session between the users; 3) Voice Chat: 
these invitations can establish areal-time voice session between the users; and 4) Web 

25 Conference: these invitation allow users to share navigation on the Web, such that the 
Web navigation of one user is reflected on the other user's browser. 
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According to preferred embodiments of this invention, a noteworthy aspect is 
how invitations are handled on the receiving end. In preferred embodiments, 
invitations are never sent from the sending user 7 directly to the receiving user 7 or the 
receiving user's client 1 1. To the contrary, at least one RS is utilized as discussed 

ttignt notbe online at all. The invitation is subnntted to me recdving user's RS that 
runs continuously on the receiving user's user server (US). The receiving RS decides 
W hat to do with the invitation according to user specined logic and available back-end 

i «; mn u t«-Yt naees mieht be handled in three different 
services. As a simple example, simple text pages migm « 

s »ohpag«itteis 0 nl im (e.g..r 1E .3,.He^^^y^«o^=b.,- M *ed 

as'Dono. a^b-.them^gev^WgoMstaboitalaBr reading. My. he mrghl 
decided*, if he* no, onUne. *. <e«p^ shoutd be forwarded as an SMS messageto 
th e irnw b i lcphon e (o IS on K o^pag^networlc)(..g..Rg.4).Tl«s M « a ppU«for 

an other types of invMons. Ttas a voice chat invuadon might actual* end up as a 
pnonecaU. if tna. service is offered in the back-end by the operator or it might result as 
a pure IP call, if both users are online. 

This funcfionaUty become increasingly osefnl as more services and networks are 
hooked.omesystett.networaoftotovendon.I.aUoisU.ebasisfor^^iono^ 

, d.eCen.UtoodterrypeWofterminaissach^smanphonesandPDA, Confront* 

ca.leeCinvi^.ForttecaUeritlddes.beo^ydetoilsonhowto.ocatoartd^cha 
givenpetsonfcserTaranygiven^.^ttecaltoitaUowshmite.ocon™!^ 
^^hbirnto^how.wi.honttavingtodiscJose any posonalinforaattonsMh 
, ^phonenumbersornerworicadd^seetotoecanar. Tbus, certain en.bodirneu.s of fins 
invention essentially define uniqne identifies for users 7, which can be used to 
conununicatowithotherosers and/or services, .lug al! cotnmunications protocols^ 
available, while still retaining a high level of security and anonymity. 
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Annnimumsetupcanconsistofasingle server n^hke running aH necessary 
services, as well as one machine running the database. However, in preferred 
en^odunents.rnultipleserversSare provided at each cluster 1 as shown in the TO 

of this application. 

cliem, tha. manpula.es to*** record, and a!*, displays alerts and logs issued from 
the cluster. 

■Om. as canba seen from Ore above, the system/network of dm invention is a 
Uehrweigh, server framewort providing a simple and secure user mode! and rouung of 
, inviuuons.oex.ema. services. As suchi, does no. impose an, rigriftcan. Umi.ation(s) 
on which service is hooked up <o fc while sdU aUowlng for a unified interface to us«s 
aMbiUmg. Usersmmffemmdusurscanconmumica^wimeachoAer.moughthe 
acmal person* user infom^on is securely he.d wimm me adminitfrative bounds of 
ihe cluster in which die user is registered. 

Set form below is a more demiled description of certain aspects of this invention. 

With regard .oscalabmry.mcertain preferred em^ 
^nd is ab.e ,o support a user base of tens of miUions of uses, wid, a coupie of 

v^ally unumited scalability as apphes to splitting load across multiple clusters, and 
» within each cluster belween machines, processors, processes, .breads etc., and load 

who>eback-e»d,b«ins an interconnection of many separate clusters 1. may be scalane 

da^tese 13-*-— I-"**— ou scalabdi^ exist. Stace databases »3 
25 ^ y canbeaca.edver,we1 1 (almoughno.wi*ou.limi B )bytt ) mwingmoneya.u.em, 

this is perceived as a good design choice. 
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With regard to being robust, given an error free run of the hardware, each 
server's uptime is preferably above 99.9%. and the uptime of the network preferably 
above 99 99% in certain embodiments. When exceptional errors occur, such as 
^aware errors, a maximum 3-5 min. lag is accepted Essentially these state that when 
5 aser ver3istakendown.orbr^ 

itsrole.Furthex.any single point of failure, such as databases or even hardware parts 
(suchas networks)^ preferably redundant and automatically taken over by ofcer parts 
if they fail. 

I, is often desirable that communication between clients and me backend be as 

^authentication when meeting » a ctot and «> encode aU messes between 

clients and the backend using strong cryptography. 

to csmrfn emboditnenu of mis invention, each operator is able to ran a cluster 
(OT clu S ^)of 5 er™ S »se M i B u^group.Th«d iS mbu tt dservcrclu»«sae 

, 5 prcf erab.yab 1 e. oi »«ero P era«raotder»n^«ainn 1 e«holeconunnra V . AddtaonaHy. 

i.ispreferablysha.spanmnngbepreven^^ 

prevensative measures and counierroeasures. 

As for the overall architecture, wherever standards ft. the needs of the 

application design, me, should be used. Moreover, any add*n s«v.ce .ha, ne*s 
2Q tott8 ^ 0 „wiran K ba Si c S erv i c«ofu,ebac k e lri praferablyc Mm «s»i..na plug- 

in" fashion. 

Turning «o<he overall server structure, reference ismade .oRgure 10. E*h 
operator runs one or more dusters 1 of servers 3. Bach clusrer 1 runs on a high speed, 
reUable and secure LAN. Reliability msy be enhanced by having .wo (or more) 
25 ^LANs.musgivmgn-l/nretodancy^eranisutenumberofduphcato 
LAKs. SecuritytoybeenhaneedbykeepingtoUNinalocltedroon, md-« 
1 are interconnected via a network connection 17 that is preferably high speed but may 
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^^asatmUableandunsecure. Note rhat to does not mean that 

wm be unseat.: U means that since the ,^0* 17 <e.g. pacta switched digd* 
network) does not psovide security, certain aspects of to inve.fi™ prefe^ly provtde 
it NotealsoduUthei^foriegardingtiKintn^^ 
uis intended*^ is noretpfire^^ 

not me an tha. the operator cannot set n P a tehable nemo* 19 if he/she sc wishes. 
Considering titerequ—todseback^^ 
sovers 3 in each cluster 1. Further explanation follows. 

Ftgure 11 mustnttesanexemplsrycluster 1 including aptaatityof aervcrs3 and 
aoaabase 13 .herein. Nnnterous ctietns 11 areconnecttdtothectas^r 1. Server^ 

n« cteter include user server, (US) 19, connection server* (CS) 21. and intia-cluster 
^ a CS02 3 .Se,fo^belowinTabielisalistofce^ro 1 can^cerui» S ervar S 

3 in the Rgure 11 cluster 1 have in certain embodiments of to invenuon. 
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Table 1 - Servers in the backend and ^their roles 




Cluster Server as needed. listens for 

connections from remote iCSs. 
Subscribes user status at other 
clusters in order to maintain 
correct contact status for local 
users. Forwards local user status 
to subscribed remote ICSs in 
order to maintain correct contact 
status for remote users. Forwards 
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1QSBKEVIA- 

<P .• 

•HON 



FUIXNAME 



DB 



EXPLANATION 



messages from remote ICSs to 
local USs. Forwards messages 
from local CSs to remote ICSs. 

(Database " All data that needs to be 

'i;f' persisted may be kept in a single 



US 



User Server 



for a given set of user(s). Keeps 
track of contact lists and blinded 
lists for these user(s). Keeps 
track of routing for these user(s). 
Forwards user status changes to 
interested CSs and ICSs. Routes 
pages for these user(s) viaRS. 

«^«MF • • ^r^;>- ■ Mapsag^venlocaluserto 

l: '"the'iiser. Monitors the status of 
'the Servers to the cluster. 

server 



S^3SS;& ")••'..'•;' through the CH> associated with 

fM^#>>ff# \ r;--^- vtonitnrs the status of : 





LoS.balances tfSs and ICSs. 
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TftON 

*: ^ Listens for connections 

Cs Connection Server ^ 

from clients. Forwards status 
updates on connected clients to 
the US(s) that is handling them. 
Subscribes on status changes 
fromUSs for the contact lists of 
connected clients. Forwards the 
status changes to the clients. 
Forwards paging from connected 
clients to US(s) and vice versa. 

„ ^ embodiments of this invention, colons Mm. servers * — « 

.„ „. t maintained between two servers 
Usmttc^esensethaucotmectren^notbemaretaree,. 

software entities wimin me ~ «*. 3 are commumcaung. Ho*ev«, 
unless sonw comecfion is already open 

coanectioo.bowo.oservmsmayteshared.sodut.f ^ 

^eco^oscrvore.to^toop^nganowco^uoawhco^ 

W^re^to^^aaon^^cac^TM--^^ 

^edaCustermCaOD). ACmisen^in.^nwaytnto ^ 
^ /t KM Q is siven a user server ID (a USID). it 

that their CID is the local cluster .deoof.tr) to USIDs. H.o 

. >. ~ m ,» work re certam embodiments of this 
eMffl ple of how Ore mapping mechantsm may work re 
ievsmioo. This mapping is dynamic since it can change tf a user server eras 
1 iemoved,orlfauserserverisadded. 
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un* of ^ M » ram. i* «*•• " «-* ta « wiy "* f " * 

• • a- came wav and for the same reasons as the RID to umu 
This mapping is dynamic in the same way ana ior u« 



mapping. 



Table 2 -Maps from XJIDs to other identifiers 



•r;i'\. •'..*,••. ; '.-V- . 
ClusterID(UTD) 

$s^Se^"erlD(local 



a— 



IntraClusterServerE) 
(remote U1D) 



ABBRE- 
VIATION 

CID 

* * • 

ICSID 



NOTES 

static mapping 

. known by UMF, dynamic 
, mapping 

" known by IMF, dynamic 
mapping 
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cm. 1* choiee of TITO is made for «n iotetopembUity - «»T W1,h 
other systems, i.e. SIP (*hieh is used for session initiation). 

Tte nature of to bactend and ore preferred robustness may caU for a reliable 

SSHprorocolrnnnfnsoverTCP/IPn^ybeeho^foraservermtercommnnrcauons 
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certain embodiments, as well as the communication between clients and connection 
servers. Tnose skilled in the art will recognized mat omer protocols inay also be used m 
toad vc embodiments. SSH exposes abstractions called "connections" and 
breams " A connection is an end-tc-end connection between two computers winch 

5 canbeauthenticatedandencryptedandwMchcanprovideda^ 

named, bi-directional flow-controlled stream between two software entties on the 
separate computers. Many sfrcamsmay be opened on any given connection, onto whrch 
they are multiplexed and separately flow-controlled. As an analogy, one may think of a 
connection as an elecuical cable, and streams as the many separate, insulated copper 

10 wires within the cable. 

Figure 13 illustrates the way the systenVoetwo* * *■ may * broken 

iflt ocompo M ^» D dsan K ofte* P =nde K i C sbc t w«nco m poaca«. E^h compel 

has various rcspoosibilHy(ies) in the overall systemfcetwork. 

As can be seen, (he user servers (US) 19 includes online status service 31, uaet 
,s routing serviced <RS) 33, device handlers 35, session service 37, user P«W -™» 
39 ,oadbala J ,cin g service41, m dcon«ictUstservice43. Connection serve* (CS) 

Mude online status service proxy 51, contact slants service 53. and lo« of scene 
^54. InUa^nsterse^ersaCSlSincludelotsofgenerrcpwxieaSS. Tbe 
famewo* undcrlysngeachofnres.serversincludesaUMFlS.norificat.on 
20 b^adcasangSl.authendc^.I/Omod^ 

^ failure detection 65. Operanon and m aintenance(0 & M)server(s)64 handles 
syarem configuration (eg., provision/assignment of users) and/or monitonng of 
servers/clients in certain embodiments. 

Still refemng to Hgure 13, tire ontiue status service 31 stores users' online 

„ w^.rfta**.^*^"'*^^^"^ the 
onUoes^semceproxySlstebetweenuteclientnandtheUSafonvariing 

^ to change the chenfe user's online status; it bandies failure tolerance in case 



WO 00/69140 



PCT/SEOO/00926 



31 



10 



asersonunesta .,, c w s ^ Iis t tte contact fat service 43 s«»««* 

et fl niQ of every user from its client s coniaci iv*. 

status ol every u» ,„HmaMee it and allows other sennoes 

WscMtact list, aUo«a the user 7 to access and manage tt, ana 

is ,o act as a dumb, byte-forwarding proxy to many 
^JonUSs^^de.ee^erSSataserverc^^en^.P- 

, ^^anowauaersvu.^and^^o^userproae.andto^^ 
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broadcastings — to Usten for messages on certain 

channels to all other components m the cluster, and to nmn0ncnt 67 as 

. ^ ^ «t?n»^ is also nan of me framework component o/ as 

althoueh code generated by it becomes pan of the system ipart 

« c^^r nnd a server, into code tor Dom lucuw 
sent back and forth between the client and the server, u 
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pooUng and synchronfcauon. diabase connection pooling. I/O usage, timed alamrs «c. 
»d abstracts these for ft. otor services. Resowce^faihucde^ttoafeBCfioa 65 
Mst^formefaitaeofUssW.ICSsJSandCSsa.anobxeadcas^^^ 
tenooficadoab^asdng^ch.^ifoaeofthemgoesdcwn.AgaK^.spai. 
ofI h=fram eWOTk co nV o=eat l ha.»»d,rUe S eachof^C S ,US,.C 3 , a »l Observer. 

defied, with Pieces of the function gemng drfined My as needed. There is aho a 
. ^ismmareclainBandnndefinea pieces te , have no, bee» used for some m>e. 
The funcu» is pmUtedW.be DB 13. mtacdro^^ 
, servers for CSs and ICSs (UsetServerUXUiD) and IntraClusterSen-erHXUlD). 
P^workoTismus responsible forp« 
^.wUchtrartsparendy^ese^ 

Load balancing service 41 auoca.es resources which are eMemal to the ctosrer in 
.faanionwhichloadbalancestneresou^^ 

B wish ,0 use the screes of serve* which see not imputed witbin the duster ye, 
fom.anta^p^ofnreappncadonandshouldumc.^^adnnn^ed) 

asconceptuaUy.partofthecluster.TT^^ 

serup and managcutcot as well as data transfer between members of the session. 

Adomos^ve tools ahow^mmadmMsu^^ 
20 sys.em.addnewusera.etc.TheymemsponsiWefornonf^g.llctmrponenBma 

cluster of changes to settings that affect them. 

mtabaseabstractionlaye^ provides aumfiedwayof accessmgthedambase 
,3 used in me Coster. Layer 69 provides access to severe. LDOs (Logical Ma Objects) 
which are user-defined Co defined by service cream*) object, in the DB 13 whtch 
25 pn.videanabs^dtmtesomedalastntcn^s^mtoedaUbKe. 
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Responsibilities of framework 67 include the following: 

A. Provide an environment which efficiently handles matters such as I/O, 
timed alarms, thread pooling, message broadcasting, database connection 
pooling and logging, hiding the complexity from the service creator. 

B. Expose abstractions to service creators which make their life easier. 
These include abstractions related to I/O, the database and data stored 
therein, alarms, message broadcasting (notifications) and logging. 

C. Perform caching of data within the data abstractions supplied. 

D. Reuse existing data abstraction object instances when this is efficient 

E. Supply a non-ambiguous method of specifying a protocol description. 

F. Implement a process which can, given a protocol description, output 
code which implements the details of how to encode protocol requests for 
sending them over the wire and how to use the I/O primitives supplied by 
the framework. In essence, this process hides from the service creator and 
the client implementor the fact that the client using the service does not 
run on the same computer. 

G. Uniquely identify instances of services and supply a registry of these 
so that connections may be made to previously existing instances. 

H. Hide from service creators the fact that when their service 
communicates with other instances of the same service or instances of 
different services, these instances may be located on different computers 
within the same cluster or even on computers within remote clusters. 

I. Ensure authentication, security and integrity in all communications so 
that service creators can always take these for granted. 
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The threading model exposed to services in the framework 67 is what has on 
occasion been termed a rental apartment An apartment is defined as "the context a 
tenant is called in". The fact that the tenant is only renting the apartment means that a 
tenant may not always be called in the same context (i.e. on the same thread) but since 
tenants only live in one apartment at a time, the analogy can be extended to say that a 
tenant will never be called in more than one context at the same time (i.e. no more than 
one thread will ever be active in the code owned by.the tenant). Services are "tenant 
owned". What we mean by this is that the code for a given instance of a given service is 
attached to a tenant The service creator can therefore assume the rental apartment 
model when writing the service, and does not need to worry about threading issues at 
all. The framework keeps a pool of threads into which threads are added as needed up 
to a maximum. These threads are then reused when work needs to be done. Each thread 
is active in one and only one tenant' s code at a time. When work needs to be done, the 
framework waits until a thread is available, hands it the assignment (a description of an 
event that needs to be processed), and marks it unavailable for the time being. When the 
thread finishes, it notifies the framework, which then returns the thread to the available 
state in the thread pool. The reason for using a thread pool is that performance 
increases as more threads are allocated to doing separate jobs, up to a maximum (system 
dependent). This means that we can only have a maximum number of threads running at 
a time, but we have a number of jobs that need to be concurrent and which need a fair 
share of the processing power available. The thread pool method solves both of these 
problems. 

As for I/O 61, the framework 67 preferably uses an implementation of the SSH 
standard protocol for all communications between clients and servers, between servers 
within a cluster, and between servers in different clusters. SSH provides 
authentication, encryption and integrity to all communications. It also supplies 
abstractions called connections and streams. Streams are the main I/O abstraction used 
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in the framework. The framework exposes an abstraction equivalent to an SSH stream 
to services. 

With regard to connection requests, an instance of a service in the framework 
only exists as long as a stream is attached to iL The process of attaching a stream to a 
service will now be discussed. Streams are opened with two explicit parameters and 
one implicit parameter. The implicit parameter is the UID of the user opening the 
stream, which we will call the source UID. The explicit parameters are the name of the 
stream which we will call the 'stream type", and a UID which we will call the 
destination UID. This UID might be the UID of the user opening the streamor the UID 
of a different user. We previously mentioned that one of the framework's 
responsibilities is to uniquely identify instances of services. We can now define what 
constimtes this unique identification: it is the type of the stream that is connected to me 
service and the destination UID as defined above. 

When creating a service, two main parts are created: an object to which streams 
can be attached, referred to asastream connector, and an object which knows where to 
connect connection requests, called a locator. A part which implements the actual 
functionality Of the service may also be created. At initialization time, a server based on 
the framework registers all the locators it knows about under the name of the stream 
type*) they handle. Any given locator is registered as the object which knows where to 
connect connection requests for streams of a certain type or types. 

We can now explain how a connection request may be handled. When the 
framework receives a connection request from SSH for stream type X and destination 
UTD Y it finds the locator registered for stream typeXand passes it the connects 
request The locator checks the destination UID, Y, and based on what the UID is, it 

5 doesonetfthefofiow^ 

fi.estreamconnectortometenantandconnectsmestreamtomenewst^ 

and registers the new tenant as "the tenant to which the service for stream type X and 
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destination UIDr is attached" (read that again* you didn't gctit, it's important; 

pair. Tins is appropriate whenit is not necessary for different connections to the 
"same" instance of a service to share state. 

The swam connect looks * the source UE> of the connection revest and 
decides aether it watts to accept the connection based on who is connecting. Mfereot 

as the locator foe more than one stream type- This means that a single service can in fact 
^connections from morethan one stream type. When we add the fact the. a 
separate protocol, specured in a protocol description, is spoken across each stream, we 
^ethat tins model s^mti. tool ahi. like we're hnptanenung a C« class whtch 
15 inherits from one of more purely abstract base classes. 

How that we have covered the details, we can step bade and see the whole 
picture. Each service has a "type" (or types) which is the type (or types) of streams thai 

Each instance of a service is "owned" by a single user (flte 
it accepts connections from, tacn mbuuw* 

, to a (service type, destination U1D) pair ti, be conneCcd to a single instance of the 
service or always to a new instance. 

Up until now we've assumed tat * entity tot is asking for the stream to be 
connected is the alien, The fact is tot services can themselves connect stieatns to outer 

^stowenowhaveaframework which suppom abstract stream I» between 
cheats and servers, and between servers and servers. 
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At times it may be necessary for an instance of a service to send a broadcast 
message (referred to as a notification) to "all interested parties" without knowing who 
these parties are. The framework supplies a method and function 57 for doing tins, as 
well as for listening to notifications that you're interested in. The abstraction that the 
framework supplies to services is as Mows. A service can send a notification (which 
is simplyabinary packet with arbitrary data) onto a specie named channel. A serv,ce 
can listen to specific named channels and will receive a call into its code when a 
notification arrives on one of these channels. 

PDL is short for Protocol Description Language. This is the frameworks solution 
for a non-ambiguous definition of a protocol between a client and a service (when we 
talk abont clients in this context, we are also talking about services which open up 
streams). The PDL compiler 63 is a software tool which takes PDL as input and spits 
out much code, both onthe client side andon the server side. On the client side, itsprfs 
out a COM DLL which implements COM interfaces specific to each protocol which 
allow client applications to use the protocol as if it were a normal COM object On the 
server side, it produces two main things: code for services to act as clients to the 
protocol, and code for services to implement the protocol. The code for implement a 
service is split into two: an object which allows die service creator to call back to the 
client as if the client were a C++ class residing in the same process space as the service, 
and a C++ class which is purely abstract which the service creator must inherit from to 
implement the methods defined in the protocol These two parts are a high-level enough 
abstraction that the service creator can, if he chooses, ignore the fact thai the underlying 
I/O abstraction is a stream (he can even ignore the fact that there is any I/O going on). 
The only concession to complexity that the service creator has to make is that all calls 
are asynchronous, i.e. if he wants to send back a "remm value" to the client he must do 
sothroughanew.separatemethodcall. Note that although PDL and the PDL compiler 
63 are suppliedbythe framework to ease the pain of writing protocol stacks by hand, 
the underlying stream abstraction is there for the service creator if he/she chooses to use 
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to. change its behavior. 

, n , . - . tn .jovide service creators with easy 

, ^itnOsfLoeical Data Objects). An Luuis^ 
^andseve^U)^ - 

specific type of data, i.e. for a specific ^ ^ servicc , either by the 

Usually it will be created in conjunction wiin m 

caching the data 

eo^n teq-u. U. U eUher «w» . acw U>° ^ ^ 

• A wl of database connections is mam . . . 

1S currently etosung A P 001 ^ io ^ gn to*eUu^P<»ln*'* amd 
layer. This is similar in fnncnon and tn dest*. 

by the framework. 

aspedflcinstaneeofaservKerestdeson Sa^ MxiS ^ 

server should almost lately be able » — statt 

25 nsin* .ha. server for ^ connecuoos *d . « 

oatheframe.0*. lnclus«ers 1 which are connected to other 
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bytetorwaromgp is reeistered for each protocol that clients 

used in the following way: A generic proxy is registered v 

* ;« n*. hack-end. When the generic proxy gets a 
• are supposed to have access to in the bacK-eno. » 

, «. r/JD-v asr UlD=z), it will accept it, then ask its 

connection request (type=x, src VID=y, brine 

tart /.„,| since the internal UMF is being 
10 framework to open a stream wrrh parameters (X * * Smce _ 

^oocssa, te v»mo^as^^^ w ™~2^ 

^ IC S 23 which is acting as a Wage m d» cluster aser : restdes on. Oa ofcer se^r 
!L (e g., US and/or .CS. generic proxies 55 are used in the same w, y . The d« 

. . j i.^nV«iseenfromanalysrsortheatjove,rne 
taecrulmappingtiinclionisirsed. As can He seen rrom , 

^ 1 modal the UMF aM generic proxies on ICSs allow servrces to 
framework aream model, the UMr- an g r any 
cormectto services for^aserttotcanbereachedrnthenetw^ 

^e.ceptme^ofso.icama.Utobeconneo^u.andtheUlDof meases^ 



20 connected to 
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• ^/dq\t* which resides on the US for a 
Routingishandledbytheroiinn g s e rvice(RS)33,whichres 

^ *,11MF25 For example, when user A sends user B a 
oven user, as dictated by the VWr £>. for exuiup 

^ , ntT,„ a« c client sends user A s routing 

se nicether n e ! »gc ; 2)UserA-sro«ring S erv,ce33oanserA S t J! , 

rouun5 ' ^ r . reives the message from user 

IISV 31 User B's routing service 33 receives mo 
service on user B s US), i) us probably 
A-srcutmg service,^ on it (tins logic 
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^sage). Opdo^.userA'scUentn.y^eU.cmcssage^apcpupw,^ 
^ the new message. A message (as a*** to me routing setvice, is a «, **. 
eg oaybefca^according^meSIPs.aadard^fo^a.ofmebodvofae 
s ^sageisdepe.de.tonmemeasagetype.IaanRSJStoagivenus^.bommc 

outgoing routing logic and the incoming routing logic can decide to fonvard me 
^ to a device handler (and opuonany process U tamer once tire devrce hand,* 
to, processed it,, srore me message in ure u^s message ho, deliver me message- 
„user's.outing service, or deUver me message down » tire user's chent. Users 
» ^re^es.mararecelprofdehveryhesen.mdremwhea^emessagemey^rs 
storedmmerecipien.-snKsaageboK.^whenu^n^sageti^sen.issen.mme 

receiving user' s client 

j _ f cerv ice attacks, the sending of multi- 
To prevent spannnmg and deiual-of-serviceaita^, 

mav not ue ano^d in certain embodiments. This means that if the 
recipient messages may not Deaiiowcuiu*.» 

parform as well as maKng » time-consuming to send messages to multiple recptea, 
Herein, adevice is anything which can receive a message Each device can 
20 receive a specific message type or set of message types (e.g., from an RS 33). Each 
fcv.ce also has a specific type, a rfcvice W A-*- ** te * * °T 
^age types it can receive, and optionally what identifier type to use to menu* me 
aavice^g. aphoue number for a pho^ terminal). Software components called 

„ concept --^JTJin^L. 
handle are normal services in eve* aspect, except for the fact that u 
canhaudletiresamepromcol. This ptutocolaHows me routing service 33 topass 
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a f«r the device handler to pass them 
^ages * the device handler for harass, and ft. the devrc 

back. 

to decide what to do wim a message) 

^vbeirapleroeateie^byauRSW _ ' atreeo f n „desa*ereall«on.leaf 
langoag e dabbed RouungT.ee. »hich — „ ^ n9<tes 

— — — SI— 

eaaberaadeona^cfp^^ ^ 
several differeat named rouung profiles may be sp 

_ <r, 1p , : K a i wa vs active as tne rouuug i*« 
One routing profile is always „, WV er the client sends a 

diff^^^^^^^^u^oaeforwben^ 
ls whenrheuserisatwoAonarooOngprofilefor 



user is on-line, etc. 



-««tH«- user to a session, accepting an 
w session iniuadon (U. lovrdng ^ (SIP . 

- — ■ ^^^r^^raar^eerlagTasKrorce. 
"SIP: Seasiou Initiation Protocol. lntemetDrarr. feralce .Tbeae 

suffice for usera to uudate conferences aad u>v«e ofce 
^.poh^conferenco. Por = ^ ^ 

^evaadV.Ucobsaa/SDP^sioaDescnp^ou^ 
herein by reference. 
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— — — : srmrs 

W0 \ild be used concurrently wnni r 0 ™<tfee oaee, 

wuiuu t~ - , , a ^ the message types ^e.g., 

t^smt* be added if necessary. 

Table 3 - Message types defined by the routing scheme 

, m „ c .;-a*««— »-*" B " ,,te, "* ,t 

page 

W ' 'i.— i-F— — ■ 
. >i INVITE request header. 



setup-reply 

cancel- -V-- : V • • *. 

.request ^ • • " 

^tauon^" Sen.when.eavtngas^on.a.aSirBYE. 

bye-request 
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^ (K the user s dent) if ,he user is ool«. The user may «"»«*«« 

...fmm the Inbox, maik them uoreador wad, or delete thoa 
she mav retrieve messages from tne inwiA, » 

oper^wmperiodi^chec.tov.ry^.m^^^vo^^^ 
l^pa^^m.meo^Xmesse.esmmsiebo^.^^ 

« up. T1* w0> be a morion of the admi, mo* and the **- 
Lover the inbox can handle the sending of receipts of sTOrage if the m^e* 

marked, 

Rg ^ 1 4 i saflo W chertU ta s^ho«a^» 5 er(e. 8 ..user#l)ea»e S ubBs*e 

^oneormoroc.us.ersoIU.enetwo*. The fust a«d second users maybe 
j^lrhesamee^oralrernarive W^emnt^of *e^* 

bmmoroltolynroasrigned.odifferon.naeraserversW.Tosnrrtnre 

^s contact list (nore ft* the UID need not include a netwo* addross of 
^suchasmeseeoorinse.sphonennn^oflPaddre.s.merobv^ade^ 

, « den, ( e. S .. PC or phone) forots and sends the INVITE n^age to *. «- 
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a eor'c 33 at the second user's US 19 (at the 

Oih«»ise, thcKcoDd uscrway ig»«e. oracc 
nessage as discussed hereto 'step 173]- 

» ^ , few exiles. ^ ^ ^ ^ „ d . „,« 

both users are at their phones. Hole tna 

P PC ,o PC rendezvous, for example, wi* reference to Figure .5 toragu* 
FornPCtoPCienuez klmina text chat conference. Carl 

^atanbyustogbis client 11 toumte A~C-1 .« 
a^ontoC^Sesslonservice^togon^sUS!,, «e P m 

eacodetheaddressof *e session (e.g..e^phonecompan,.co,n, sessronn 
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SIP INVITE message (step 73) and send to to Anne [step 75]. The INVITE message 
would be directed by Carl's RS 33 and Anne's RS 33 in accordance with how rhe 
respective user's had programmed tor respective RSs.m the nonnal case, if Anne was 
on-line tire INVITE message would be directed to Anne's client <e.g., Anne's PC). Anne 
to<b ,^ S wheto»accep.ofdecteti K invi Q tion[s«p77].IfAnnedecid«» 

accept the invitation. «• *ould cause her client 1 1 .0 connect * the session encoded > 
d» INVITE message [step 79] . If Anne decides to-decline, she may eito ignore the 
INVITE message (step 81] or may send a dining message to Carl's client [step 83). 
To invite William, Carl would use his client to add bin to the session. William would 
receive an INVITE, accept it in a similar manner, and join the session. 

For purposes of another example, consider a PC to phone rendezvous (e.g., see 
Kg 4) Catl(nserA)i S athi S compn«r(e.g.,PQ?ndwan B lovoicecha.withAnne 

(user B). Carl chooses mis option in bis client 11, which then sends an SIP INVITE 
message to Anne as discussed above. Anne, however, is «t at her computer («.. 
Anne's client 11 Is not online). Upon receiving the message, Anne's routing servtce 33 
norestoshe is off-line buttosb. has asked to voice cbaa torn Carl be forwamed 
to her GSM phone. Thus, Anne's RS 33 sends the message along with the phone 

n.essage.mdevIcetentolOse^upacdllegmAm.einanexternal voice gateway 

Carl to the call leg already set up to Anne if he calls ft. then sends bade a reply to the 
SIP INVITE message to tells Carl's client 1 1 to Anne is temporarily moved to the 
temporary number just setup. Carl's client 11 calls the number (using some IP 
telephony system), hears .ring, anddten Anne answers to complete the rendezvous. 

AsanotherexamplceonsideraphonetoPCrendezvous. Assnme Anne wane •> 
nse her GSM phone (U., Anne's client) to call WiUim She diak Ms phone number 
(this kind of doub.e mapping is necessary since the phone system only snpports phone 
numbers as addresses, no. system/network VB» A voice gateway receives any call 
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setup request to this number, including Am*'s call se«p request It contacts a devK* 

5 back an "accepted" response to the SIP INVITE containing the phone number, has cheat 
is registered for the rendezvous in the IP telephony system he is using. William's 
.outing .ogic in his RS 33 rowes the message back to the very same device handler 
which sen. the original SIP INVITE. Upon receiving the message, the device handler 
" sa ,dsme.e te pl»nenunAe I fromu K me ffi agebacku,mevoicega KW ay,v,mch 

„ forwards the call accordingly to William. William's client pops up an "incoming call- 
dialogue which William decides to answer. 

As yet another example, consider a phone to phone rendezvous. Assume mat 
WiUiam wants to call Carl. He picks up his phone (William's client) and dials Cart's 
pbnne number. This case is the same as me Phone to PC Rendezvous case above except 

l5 tat Carl's touting logic in his RS 33 notes that he is offline, and thus per Carl's 
tanKdons/progrturmtingset^ 
spedfied for when he U otfnne to a devte h^ 

-fcmporarily moved" message, which makes itback to the device handler which 
originated the INVITE, then back to the voice gateway which forwards the call to the 
20 specified number. 

As discussed above, services that facilitate things like knowing the online status 

„ a hierarchical Us. are also available. These services are provided by to foliowurg 
components: Online satua service 31 and online sums service proxy 51; Com*, sums 
23 service 53; and Contact list service 43. 

Figure 16 shows dam structures Ota. are kept on each user server (US) 19 by me 
o^ service. This is only a rough sketch thar shows the most important dan. element 
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Figure 17 shows the data structures for the contact status service on each connection 
server in the same manner. Both of these data structures can be considered volatile and 
are kept in memory for efficiency reasons. The useTs online status is subscribed from 
the responsible US 19 by CS(s) 21 that are watching the user as someone's contact The 
CS that is connected to the user's client can update the user's online status (through the 
user service/user service proxy), and MsAer contact Ust. When a US 19 gets a contact 
Ust request on a user that hasn't been loaded it loads the user data from the database. 
The user data is kept loaded while any CS21 is using iL When all CSs have released the 
data, it can be unloaded from memory. The data may be kept in a cache of some sort for 
a while from where it can be quickly loaded. The version attributes of the Usts serve the 
purpose of being able to know when to update the cache in a CS by checking the 
version number of the data stored on the CS and comparmg it to me version nuniber of 
the data stored on a US. 

In d» contact status service 53 on a CS 21, each connected user has a contact 
list. The contact status service subscribes to the online status of each contact that * ts 
etching &om a corresponding user service on a US. Ids drenser service's 
responsibility to filter on, bunded users when sending status updatis. figure 18. shows 
U.e data smrco^ srored f« the con^ lis, ser^ 

database 13 andreuieved on demand. Each user has one blinded lis. and one seeing b* 
one of which is active at a toe. If b. bunded lis. is acti ve, all osers except those .» the 
blinded Bs. can see this user's online status. If on the outer hand the seeing lis. rs active, 
only users on the seeing list can see this user's online sums. 

Refemngu.Hg^elS^order^access^^nerivorlcofdUsinvenhon.a 
nserVmustfirst ,og on. Hgnm 19 filnsu^ an example of flreaiessage sequence when 
s a user U, logs onto the system. When Are CS 21receives the authentication request ), . 
first checks die passwori for validity. The nser may have been onregiaered, «c. Then 
authentication is formed. In .beetle, the user's UID hasn't been used before. 
The CS must therefore ask die UMF for US1D. The UMF 25 selects an available US 19 
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with the least load to be responsible for that UID. The CS now sets the online status for 
U, on the responsible US 19 and retrieves the contact list. In the example U, has one 
contact, namely B ,. The status for that contact must be fetched from the corresponding 
US of that contact. After that, CS subscribes to B.'s online status. The US 19 of the 
5 contactuserB, ^T^V* l *c^CS*«*dk*~™*<^*"* 
contact is off-line until they receive a status message. 

Figure 20 shows an example of the message sequence when a user U, logs off 
the backend. Now the CS 21 sends a logoff message to the US 19 responsible for U,. 
The US sends status message to all subscribers, saves the user data and unloads it 

M Figure 21 shows an example of the message sequence when a contact B, logs on 

and off. The user U, is watching B, via user Ufs contact status service. When the 
contact user B t comes online, the US of user B, sends B,'s online status to all CSs 21 
subscribed. In such amanner, a user can monitor the status of different contact users B 
throughout the system/network, without the contact users B knowing that their status is 
15 being monitored 

Figure 22 shows an example of the message sequence when a user 7 adds a 
contact to his/her contact list and then removes it again. It is the US's responsibiHty to 
keep the contact list updated in (he database 13. When a user is added or removed as a 
contact on another user's contact list, the user who has been added to another user's 
M contact list receives notification in certain mbc>diments, as shown in Fig. 22. One user 
7 may add other users who are or are not assigned the same cluster to the adding user's 
contact list 

Figure 23 above shows an example of the message sequence when a user adds 
another user of the system/network to his or her blinded list and then removes it again. 
* ItismeUS'sre^oiisibmtyCt.e.meresponsmiHtyof theUS 19 of the adding user 7) to 
keep the blinded list updated in the database 13, in certain embodiments. Note that 
when a user A adds user B to his blinded list, user B doe. not get any notification that 
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this was done. The idea is that user B should not know he or she is on user A's blinded 
list. Figure 24 shows an example of the message sequence when a user inverts his or 
her blinded user list. This sequence is similar to the one when a user is added to a 
blinded list. 

5 Set forth in Figure 25 is a summation of database 13 operations needed for the 

contact list functionality. As can be seen, in preferred embodiments, the user server of a 
given user 7 is responsible for most actions relating to contact list functionality of that 
particular user. 

The session service 37 handles session management. The user that initiates a 
10 session (i.e. creates a conference or initiates file transfer) owns the session. Other users 
7 get invitations to the session which contain directions on how to connect to the 
session. The owner of the session can invite other users (through the normal message 
routing mechanism), kick users out of the group, mute users so that they become 
observers, and/or end the session which causes all users to exit the session. Entry into a 
15 session is by invitadon only, and this is preferably handled by the session management 
server keeping a list of users that may enter the conference. The owner of the session 
adds to this list when he or she invites other users. 

For every user 7, a certain set of data is stored. The data is kept in key/value pairs 
call properties. These can be global for everyone to see, private only accessible for the 

20 user him self or it can be access controlled. Figure 1 8b illustrates a data structure for a 
user profile according to an embodiment of this invention. The user property service 39 
of a given user controls functionality and storage in this regard. Moreover, a "find user" 
service may be provided in certain embodiments, for enabling clients to find user IDs of 
other local cluster users by searching on their user properties (same properties as in the 

25 user property service 39). 

For each cluster, there will be a single scaleable, robust, relational database 13 
which contains all of the data the system uses which must be persistent. For smaller 



WO 00/69140 



PCT/SE00/00926 



50 



setups, this may be a single computer running a database such as Oracle or Informix. 
For larger setups where there is a very large number of users and a greater stability 
requirement, a cluster of high-performance computers reading from and writing to the 
same database will be used, and the database may, for example, reside on a mirrored, 

5 hot-swappable RAID setup. In this way, any level of redundancy can be achieved as 
well as the ability to deal with practically any number of users, without losing the option 
of running a small, cheap setup. The database 13 preferably contains the profile 
information kept for each user. The database will also contain the contact list and 
blinded list for each user. The contact hst is a hierarchy of groups where a user can be 

10 part of more than one group, and a group contains all of the users it contains and 

recursively all of the users in groups it contains. Also stored in the database are the data 
for the different routing profiles for each user, along with data which describes which 
profile is currently active, etc. Each user's Inbox is preferably stored in the database. 
This is a list of messages along with inf ormation on whether they are read or unread, 

is ordered by time of storage. Also stored is a transaction history for the messages. 

Possible transactions include ADDED, DELETED, DESTROYED, MARKED READ 
and MARKED UNREAD. The DELETED and DESTROYED transactions are 
equivalent as regards the server system (i.e. they delete the message from the database) 
but are kept as two separate transactions for increased flexibility in the client (e.g. the 

20 client could use DELETED when it wants to delete a message both from its local cache 
and from the server, and DESTROYED when it wants to delete the message only from 
the server; the different transactions will allow other instances of the client to provide 
the same end-user experience). Moreover, all settings for back-end servers are stored in 
the database in certain embodiments, as are logs from the system, both logs for 

25 adininistrative purposes and logs for billing purposes. All settings for each user's client 
are also stored in the database in certain embodiments, except for settings that have to 
do with the client's location, e.g. firewall settings. 
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Turning to scalability, let us define a mathematical model for use in deternuning 
scalability. Reference is made to Table 4 below. 

Table 4~ Symbols defined to use in the mathematical model 

SYM- DEFINITION 
BOL 

A Set of all users. 

N IJAfl, i.e. total number of users 

n Number of online users. 

B(U ) Contact list for user u. It is given that B(u) £ A ; : ; 

Uu) Blinded list for u. All users but users in L(u) can see 

u's online status. L(u) £ A 

POD Users privileged to see u's online status. Only us^fo! 

■ pco) are aUowed to seeu'soaline statm. P(u) C A. CEithcr^ 

t Hn) or LOO are empty) , .! "O 

Ncs dumber of connection servers. 

...... :;, r 'r 

Nus ' Number of user servers. ; ■>}. - . 

Nr " Number of user regions. The user space is divided 
into N R regions. Each region has N/N R users. 

j ;. Avemgenmriberofcontacum 

; ; V . Assumed to be a constant \ J -f-yV 
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! Average number of users in any given bUnded list 

Assumed to be a constant 

WhM W*nce N ,nd n tov, on bow »^ load nmtin, smicc on 

USS (CSs do not participa* in routing) may be of mtereat. We assume the foUowing for 
Ration: nO^^.o^-y^oo^onaUC^.TV^of 
cot^cko users on each CS is ^ 2) H« wort required to decide the rounng fa a 
single message based ralttl ero«nog.ogic.A;3,T t ewor k r« pire d«, Se ndame SSa ge» 
i.sdesr^or.onoedK^fori.has^de.ern^Uacoos^^aM^Tte 
nu^rofn^agosduur^u.berou.edperuserperdmeoni.iaacona.^fi 

Given these sumptions, .he rooting service causes load on each US which is of .he 



order 



Since is consant. we can keep n* load caused by the service on c*h 

US constant as n increases by increasing Ncs. 

^edbynrecon^Usts^ceon^hCSnuybeofinUrestWeassumenre 
following for simplification: 

. OnUneusersaree^^ 

connected users on each CS is nlN a . 

• AH contact lists are of size/. 

. Tto number of events from clietus per user per time unit is a consont 
Such events include: logging on. logging off, changing user status, 
adding users to B(u), removing users from etc. As a consequence 
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the number of subscription messages from USs per subscribed contact 
per time unit is also constant. 

• Following our last assumption, we assumejhat the load on a given CS 
caused by events from a single connected client is constant, denoted by 
a. Additionally, we assume that the load on a given CS caused by 
subscription events from a single contact, is constant, denoted by P- 

• The connected users on each CS do not have any mutual contacts with 
other connected users on the same CS. Further, no connected user has 
a contact that is connected to the same CS. This is the worst case, 
usually connected users share some contacts, i.e. some two connected 
users x and y will be interested in following the online status of the 
same contact z — users x and y share the contact Z. Given this, any CS 
has to subscribe to fnlNcs users. 

Hereby we can see that the load caused by the service on any CS, given these 
assumptions, is of the order 



As a +7J5is constant, it is clear that by adding more CSs to the network as n 
grows, the load on each CS can be kept constant. Hence, the CS part of the network is 
scalable. 

Most likely some contact sharing will occur on each CS, decreasing its load. 
However, the contact sharing will decline as N grows. This is clear because connected 
users can have contacts from anywhere in the user space A, and the chance that any two 
users share their /contacts decreases as A grows. Experience shows that in systems like 
the instant invention, users win group in cliques. In a clique, each user will have nearly 
all the others in each of the other users' contact list. (Note that the mathematical 
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definition of a clique is stronger. In a mathematical clique, each user would have all the 
Qther users in its contact list) The chance of contact sharing may be increased if users 
are connected to CSs in such a way that they are likely te be in a clique with some other 
connected user on that CS. The likelihood may for example "probably be increased by 
connecting users to CSs by their geographical position. 

Similar to the previous section on connection servers, what influence N and n 
have on the load caused by the contact list service on each US 19 may be of interest. We 
assume the following: 

• Online users and users that are on an online user's contact list, are 
equally distributed on all USs. The number of users on each US is 
n/Nus- 

• All contact lists arc of size/. 

• The number of events from CSs per user per time unit is a constant. As 
a consequence the number of updates to subscriptions that need to be 
sent to CSs per user per time unit is also constant 

• The load on a given US caused by events from a single online client is 
constant, denoted by ft The load caused by subscription updates on a 
single user that need to be sent to a single CS is constant, denoted by 
(a. 

• The network is large enough such that N us >=/. No contact sharing 
occurs in the CSs. Thus, subscription updates for a single user have to 
be sent to/USs. This is the worst case. 

The load the service puts on any US, given these assumptions, is of the ordeV 
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As with the connection servers, by adding more US to the network as n grows, 
the load on each US can be kept constant Hence, the US part of the network is scalable. 

As for reliability issues, a cluster 1 is an asynchronous, distributed system 

5 including the following discrete components: 1 ) Connection Servers; 2) User Servers; 
3) User Mapping function; 4) Database; 5) Internal Network; 6) External Network; 7) 
Clients; 8) Intra-cluster servers. We assume that the Internal Network and the Database 
implement their own redundancy and achieve close to 100% uptime. To meet its 
reliability requirements the Community Server Network therefore has to be able to deal 

io with the following types of errors: 1) client failure; detected by CS, affects only the 
client mat failed; 2) External Network failure, loss off connectivity with one or more 
clients; detected by connection servers 21 and clients/corrected by throwing away the 
Session State on the server side and establishing a new connection from the client; 3) 
Connection Server failure, a hardware or software failure that leads to the loss of a CS; 

15 detected by connected clients, and corrected by clients by reconnecting; 4) User Server 
failure, a hardware or software failure that leads to the loss of a User Server; detected 
by connected CSs and/or the IMF, and corrected by removing all mappings to ihe 
afflicted US from the XJMF and broadcasting a request to all CSs that they selectively 
flush their UMF cache (affected CSs then throw away any session state associated with 

30 the lost US 19 and reconnect to other, newly assigned USs), 5) Intra cluster server 
failure; same case as US failure; 6) User mapping function failure; detected by Uss 19, 
and corrected by the USs restarting the UMF 25. 

With regard to logging, auditing and/or traceabUity, all relevant events in the 
system may be logged to the database 13. These fall into two main categories: events 
23 that are of interest to the administrator, and events that can be used for billing. For each 
event, the date and time of the event are stored, as well as which user was responsible 
for the event Each event has a type, and may possibly have some additional data 
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attached to it. When logging a request made through the client to server protocol by a 
user to a CS, the IP address of the user might be stored as well. Administrators may use 
special administration toots or simple SQL queries to do admiiristrative tasks such as 
see which user accounts have unsuccessfully attempted to authenticate themselves more 
than once or twice in a row (to detect hacking attempts), count the number of users who 
were logged in at a certain time or over the whole day, or to see which events took place 
just before and at the time the system crashed (to try to gain an understanding of the 
reason for the crash). Community operators can use whatever means they like to gather 
data from the server for billing purposes. 

With regard to security and user authentication, every registered user 7 has an 
assigned user ID in the local cluster 1 in certain embodiments of this invention. As part 
of the registration process, me user selects a password for accessing his account The 
user presents his/her user ID and password to the cluster 1 each time he/she connects. 
As for server authentication, each CS 2 1 is supplied with a public/private key pair. The 
public key of the pair is certified by some Certificate Authority (CA). Each time a chent 
connects toaCS, it getsacopy of the server's public key and the associated cemficaie. 
The client can verify the authenticity of the public key by checking the certificate, and 
by verifying with the CA that the certificate has not been revoked. After receiving the 
server's public key and verifying its authenticity, the client authenticates the server by a 
, cryptographic challenge-response, in a similar fashion as for user authentication 

With regard to communications security and client-server communications, in 
certain embodiments of this invention all communications between a client and the CS 
are secure. The SSH 2.0 protocol is used in all clients-server communications. SSH 2.0 
handles server authentication, chent authentication, data integrity validation and data 
B encryption. The client connects to distinct services on the server cluster thebymepnsof 
opening multiple SSH channel,, each of which is separate virtual stream. As for server- 
server communications, the network that handles communications between User 
Servers 19,theUMF25 and Connection Servers 21. is assumed secure and protected 
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fto „ M »4 0 rized*ceas.Neito 
con^cadonsbet^U&ince^ 

CSs ConunnnicatioosletweenCSsZl andUss WnJayuaetoeSSHZOprca-eoL 
, mdisabW fors»ohco ffl «c ti <«,s 0 cdyd K s t r«am m dd pl ex fa gf^t y ofS S Ho«l 

p^cw^.--"-"^*-*- TT-eSSHS-Opro^nuybe 
Ldforsuchconmiu^^d^-v"— aioa performed by rneans of 

^H«/pn««c^^y^^«« W * re ^ ra ^" 
I0 ta ^a r =>clud i n g hc^ roM ing*ed a «aba S e 1 3.CSs21, USS l»^UMF25 

physicaUysecurrffam^o^^ssa^^periasbyteC^^ 
co^oadsed, si- anyparrof rheOuaer « conrain or cany — «on, 
Moreovera.h^^ConoccdonServersBeoatoboor^t^tt.c 
MyS e ea n c on^cBe nlS 'm 1 ffic i ncl e a rt *^al S oco n0 in^o W np n va K 

.MM. Connection Servers are ab.. » lo* ever, common and connect 
^pt.^ger.^indndesuchinformadonasftedaKandtoeof aaycr.be 

& reason for auction failure. For sueeessful connection,. Connection Servers 
^onaUybgdretinreof disconnection^ 
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10 



15 



^ traffic the Interne, destined for the Connection Serve* to prevent 
hacking and to keep track of any hacking attempts. 

Settings foreachc«^^tof theback^d^pteferably WinteDB. 
from where b. component reada fl^m npnn startnp. ^ senings ate preferably 

^podfleaitofchangeaMseuingaasianeceasnry. Hgure 26 Ulus,rama .he adrmn 
rooPa .ocation inacluamrl. Adding nsera to the application and removing naera ftom « 

user's information into m= databaae. It shall he possible » rnn -his administiadon too. 

from the command line, fca use wirh CGI programs etc. 

As can be seen from the above, a uaer 7 ia able to create new profiles, delete 
profiles, edit profiles etc. and he shall be able to se, which profile ia cmentiy acuve 
Smart touting is based on *cnsa'acune»Uy active profrle am! basically means tot 

whenever another specific user tries to contact the user using a specific mode of 

comnnmicadonti.a,u S erwmbero»«c4maconvcrsadone,»M»in.orm«a^ 

.positorywhichcanhandtematn^ofc^um^on.B^onse.bngsmme 

P^^^uaercoumbero.md.om.aum-repto^-pond.^tou^ 

d«snmeh ta anddo«snnwan,hJscaU S ,orbepu.,h I ough,o I heus CT 'sGSMe tt . 

ThesenKxtes of communication/conversation types shall be available: terf, 
, voi ce andvideo.ThcsemcaaageweashaUbeav^Iable: VoicefVM), Shortte* 

od.erLnSTM.CKM). The fonowing devices ma, be supported. Wehstwhtch^ 
of messages they are repositories Tor, which types of conversations they can takeparrrn, 
and which types of messages they can send. 
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Table 5. 



Device 



10 



Repository for 
these message 
types 

STM, NM 



Endpointfor 
these 

conversation 
types 

Text, Voice 
Voice _.. 

Voice 
Text, Voice 



Can send 
messages of these 
types 



STM 



STM 
STM, EM 



Inbox 
cHeiit 
Standard 
phone 

GSM phone STM, NM 
Auto-replier 
Web page 

Pager STM.NM 
Eiriail client STM, EM 
Voice VM 
mailbox 

Fax niacsbiiie STM. EM 

It shall be possible to create additional devices as needed (eg., conversational 
a c ent). As for the devices above, the auto-replier device is basically a device which the 
Jer 7 can set up to reply differently to different users, using voice and/or texL This 
device is an integral pan of the instant system/network. In the case of voice 
conversations, only the clientllis able to initiate a voice conference between more 
than two users. The inbox receives all STMs sent to a user, as well as notifications of 
delivery of messages (e.g., when the system routes an email to the user's fax). The user 
can specify which types of message deliveries he wants notification of. The cheat can 
give access to the inbox, and notify the user of new messages arriving in the inbox. In 
thceasematuserAtriestocontactuserBusmgamcKte 

type that user B does not support (i.e., user B has no device capable of participating i« 
themodeofcommunicationorreceivmgmemessagetype)^ 

A of this. 
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As fortext conferences, ooch conferences con handle tens of usee per 
conference. Tie user who initiates the conference preferably tas ownership rights in 
the conference, which gives that user the ability to invite nsers to the conference, fa* 
asersffom the conference and ntakensers silent Witt, regard ,0 voice conferences 
^conferences can preferably handle no less titan d^^nntber of nsers tiw tire MCU 
OT equivalent titat the application depends on can handle. The user 7 who initiates tire 
conference preferably has ownership rights in tite conference, wMch gives Idmmet tite 
abUi» to invite users to the conference, lick users from tire conference and mate users 
silent As for web conferencing, this is the name given to the feanue of the uses 7 bemg 
aUetojohtateXtconferenceoravoice conference with all of the odrer users browsing 
tesamewebpageashim/her. In web conferences, uo user hns ownership rights. Web 

0( .he application). If there are more titan tins many users viewing tire some web page, 
te y will be split too groups of no more man X users. The user interface for web 
conferences may mahe it easy for users to create their own text, voice or vtdeo 
conference and to invite use* .otitis conference, it shall alsornalce it easy for the user 
« see which of the otirer users in tire conference have the capability to join a votee 
conference or a video conference. 

With regard to voice mail integration, a user 7 can enumerate the contents of 
his/her voice mailbox through the application CU. see how many messages there are, 

etc.). Auser7can alsotoany of the message, in his/her mailbox using the apphcatroo 
A user 7 can also send messages using hio/he, standard email p-gram, from the 
appucation (eg. by clicHog on a contact's e-mail address,. It may be possible for the 
, ^rogetnottftcauonofwhenhehaanewemaU^heclceveryXminutes). Iftherets 
newentai^uaercaneasi.yb.ableton^emesystenVneb.orlcopenmsteemad 

^ogram.oreadmemessageo.Apanfr^WsfunctionaUty.titeappUcation^y 
forward different message lypeo to the user's e-mail box. The user can have an emarl 



WO 00/69140 



PCT/SEOO/00926 



61 



address which is specific to the system/network of this invention, this being done so that 
die system/network can route email, and also for anonymity. 

The system/network of this invention is preferably designed to be accessible via 
many different clients/users. The functionality of the application back-end can be 
accessible from any client (although bridging work may be required). Several clients 
fall within the scope of the application. The "full client" features text and voice 
capabilities, and is a standard GUI program with a persistent connection to the server. 
This type of client is the one we are usually referring to when we say M a user shall be 
able to do X", i.e., this type of client is the one that allows the user to do X. Other 
clients are either stripped down versions of this one, or very limited clients. The "thin 
client" is a stripped down version of the full client which lacks one or more of Us 
features (e.g., audio chat). The M web client" is a very basic client to the application 
which enables users with nothing more than access to a forms-enabled browser to send 
anyone in the community a page. There is no requirement of being able to receive 
pages via the web etc. The web client may optionally also enable the user to switch the 
profile currently being used. Optionally, the web client may enable users to view the 
contents of their inbox and read received messages. The "phone client" is a client 
which allows the user to phone a given number {& la voice mail) and switch the profile 
currently being used. 

There can be, e.g., two categories of users that access the application. For 
paying customers (i.e., telco end users) the requirement is made that no matter where 
they log on to the application, the user experience is identical (i.e., no data is stored at 
the client side). This requirement is not made for Internet end users. 

Back-end administration can be manageable at least through command-line tools 
or equivalent and optionally through user-interface took. How registration of users is 
handled may be decided on a per-telco basis; in one case it might be through the explicit 
entering of data and running of administration took by a telco employee, in another it 
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might be through a CGI script or equivalent running the administration tools with data 
gathered directly from the user. 

One aspect on the back-end regarding administration is the logging of 
information. It may be possible to log every detail regarding the operation of the system 
which might be pertinent to the operator. Which details are logged shall be 
configurable via an adininistfation tool. It shall be possible to easily import log dara 
from the system into other software packages for analysis and archiving. 

In certain embodiments of this invention, as many parts of the system as possible 
may have well-defined interfaces to the rest of the system and be as self-contained as 
possible, thus facilitating a plug-in methodology in the implementation of the system. 
This is so the implementation of the various parts of, for example, telephony 
integration, can be split among several separate groups. It is also made for future 
compatibility with as-of-now unrelated systems, e.g., the conversational agent 
technology. 

The application can provide users with a single, centralized address book which 
stores user information on every user in the community. This address book can store, 
e.g., each user's full name and email, community name, and user ED. It may optionally 
store other things such as interests, home page URL. telephone numbers and such. The 
community name and email can be public information. For the rest of the information, 
the user can define which users are allowed to view it and which not, by specifying 
groups or inverses of groups along with users and combining these with boolean 
operators. Users do not have to be able to browse the address book (U., page through 
it) in all embodiments. They can however be able to find users in the address book 
based on searches for whole strings or part of strings in the name, email and community 
name fields. Also, it may be possible to find a user based on the whole of his user ID. 
If many users in the address book fit the search pattern, the user who initiated the search 
shall be presented with all of these and asked to choose between them based on as much 
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additional information on each user as can be given. For example, once user 
Snooglepops has found user Muffin in the address book, Snooglepops can add Muffin 
to bis personal buddy list (i.e., contact list) and also can send Muffin a page without 
adding him/her to the buddy list, as well as being able to request that Muffin join a 
conference. 

The buddy list (a.k.a. contact fist) is a set of users. These users can be organized 
into a hierarchy of groups by the user. Users may occupy more than one group. The 
user can create and destroy groups, and add users to or remove them from groups, as 
well as being able to move or copy users between groups and move groups from one 
place in the hierarchy to another. Groups are containers for users and groups. The 
following groups exist by default 

Tablet 

Everybody ''V : This group is composed of all users that belong to the 
: - : vt " U" same community, whetherthey are currently on-line or 
not.. This group is not visible, in the user interface, but 
:•: -Cljfifcc. can. be used when specifying access to data. 
Buddies This is the sum of all your buddies, the root of the 

buddy list hierarchy. 
ISvirfbte 7 ^ } This is a special group which the user can add 
v amwyragu&kto. Users Mthis group shall not be able 

f> ■■• '• Vffih user's online stato, (this may be done by 

'? always showing them that &e user is off-fine) and no 

?■? • ;' •• S. >; messages from users in thi$ g$up ever reach the user 
• c 3 ! ' ! (although to die annoying iosa sending the message 
V. .■■'''§■?' t homing win indicate that tne' message was not 
i ''">- ' . .'*%t 'i revived). This group is riot part of the buddy list 
* ' .x'v • ' laierarcfoy but in a separate hierarchy. 
Frequent This is a group composed of the X last users the user 
contacts sent pages or initiated conferences with, where X is a 
user-settable preference. This group cannot be used for 
access control. 

A user can have the option of getting a notification whenever another user adds 
him/her to the other user's buddy/contact list. Moreover, by glancing at the buddy list, 
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norification of change. fate0 *e^ of buddies, «w.U as providing 
lettable audio notification. The user can view me infonnadon s,or=d in me giohal 
address book for any user in his/her buddy list 

As for paging, a user can send shot text messages (STM) to any user on his/her 
buddy lis. and «o an, user M he/she finds using d. address book. Whelher or no. 
Cese messages are se*n by Ore raving user depends on me recipient onBne s*ms 
- audonwhed.erorno.hehasmadehunself mvisible .o the sending user. ThedefauU 
way of receiving messages is through die client. Apart from .his, users can specify a 
, OSM phone number capable of receiving SMS messages ma. may be used in erflier of 
the fofiowing ways (user-sedable): 1) The user may specify that all messages m 

^. 2, The user may specify *a. a« m^sagea ma. ^ve while *e user is away 
b(m his/her fcrminal or off-line be forwarded ro me GSM phone. 

There may be a maximum size for short «x. messages, or shor. »*, messages 
when forwar^maQSMphone.hronghSMS.mich.s done isa 
^decision, ^sendi^.shor.^measage.whemerreplytagroamessage 
s e 0 .b,anod«u 5 e I ori^d«u 5 ercanselec.oneo,hi 5 merpre^n fi gured sR ^ 

^^^^^^^^^^^ 
, TO .p»«of ms^bnddylisti.nmybepossmlefbrur.p^uaerm^.hepw 
J.oms/herhuddyUs.andalsomrep.ymndamessagee^ywiUKiu.admnghim.o 

his/herbuddy lis.. W«n a user is paged, there can be an easy means for ma.user.0 
tovitt die sender of .be page .0 a «* or voice conference, In certain * 
usages may he denoud urge*. ,n certain embodiment U ma, he pos,ble tor noser 

^. The tohdnumber of users mantis^^ 
to prevent use of this feature for spamming. 
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There can be two different user interfaces for initiating conversations or sending 
messages to another user, one for inexperienced users and one for experienced useis. 
The one for inexperienced users may take more time to operate but can be easier to use 
with more helpful descriptions of actions and more pictures etc. to help the user along. 

5 The user's client preferably can display a list of all past outgoing and incoming 

messages, along with at what date and time they were sent, to/from whom, and what the 
contents were. The user shall be able to delete messages from this log to save space. 
The user shall be able to limit the messages displayed by one of two criteria, or a 
combination of both: whether they were outgoing or incoming, and to/from which user 

10 they were. Also, it may be possible to display only actual messages (no notifications). 

Short text messages (STMs) sent to a user's inbox can be readable dirccdy from 
the Inbox. In the case of notification messages which notify of the delivery of a 
message to some message repository, it may be possible for the user to ask for the 
application to retrieve the message. The application can then check the message 
IS repository for whether the message still exists, and retrieve the message if possible. 
This can be possible in some cases for voicemail and email, but not for fax messages. 

A user can set up an assortment of stock messages (Tin away", Tin busy", 
etc.). An automatic reply is when one of these stock messages is used automatically by 
the application on behalf of the user. Every user can have an online status which 
20 defines whether or not that user can be reached and which auto-reply is used when 

another user pages him/her (possibly no auto-reply is used and the user is free to answer 
for himself). For this version of the appUcation, there can be a fixed set of online 
statuses for a user to choose between, as in Chart 7 below: 



Chart 7. 




*Orime but* Only urgent messages get through immediately. 
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occupied others arc auto-replied with a stock message the 

user can choose and will be shown to the user 
when he changes to the "online and available" 
mode. 

;0^e bjatiway .**$.' Messages do not get throu^ immediately. The 
-Jp^i^a^^l V' *.£ usermay choose ah auto-ieply for messages sent 
'■'J- '■•f-*?-,~ *. m him while m this mode. 

Off-line, not Same as previous. 

available 

The user may specify users or groups of users that can get through to him/her 
even if his online status is do not disturb. Any of the groups defined in the buddy list, 
or the inverse (i.e., all users not in the group) of those groups, may be used to specify 
ibis. There can be one generic ready-made stock reply for each online status available. 
There can also be one ready-made stock reply for each online status which indicates that 
the message has been forwarded or duplicated to the user's GSM phone through SMS. 
The user can choose whether or not to let senders of messages know that their message 
was routed to his/her GSM phone. No requirement is made of being able to answer 
messages using SMS, or of being able to send a message from an SMS system to a user. 

With regard to text conferencing, a user 7 can send any user on his/her buddy list 
or any user that he/she finds using the address book a request to join a text chat 
conference hosted by the originating user. The request may be accompanied by the 
user's explanation of why it is made. When receiving a request to join a chat 
conference, the receiving user can choose to join the conference or not to join the 
conference, or can choose to ignore the request (this is what happens when you are 
invisible to a user, and that user invites you to a conference). The user's response may 
be accompanied by his reason for responding as he/she does. Once a conference has 
started, the originating user has special privileges within the conference, and can invite 
additional users to the conference (may be accompanied by an explanation), kick users 
from the conference (may be accompanied by an explanation), and/or give or take away 
the right to speak in the conference. All users in the conference can use text to chat, 
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and the conference shall display a history of the messages sent by the different users 
(e- IRC etc.). All users can also emote (as in IRC) their feelings in an easy way, lc, 
to let other users know they're smiling. Text conferences may be able to handle at least 
20-30 users. When the user with special privileges quits the conference, the conference 
5 is preferably disbanded in certain embodiments. 

in voice conferencing embodiments, a voice conference is a text conference with 
the added ability to chat using voice. When multiple users speak at once, their separate 
inputs are mixed together to form the output. Audio quality may be dependent on the 
codec used and possibly on the bandwidth available. It is presumed but not a 
10 requirement that the GSM codec will be used. Only users who have the capability to 
receive and send voice signals can participate in a voice conference. 

As for video conferencing between users 7, a video conference is a voice 
conference with the added ability to see the user who is currently speaking loudest 
Only users who have the capability to receive and send voice and video signals can 
,, participate m a video conference. Another option can be the implementahon of Web 
Conferencing between users 7. 

The application is aimed at « who have access to the Internet and an account 
with a telephone company, and have received their application from the telephone 
company. These users am anvttnngftom novices to veterans who wish to use the 

> Tnttmetforcommunication. The application is also aimed a. users who have access* 
tire internet and have received their application over the Internet (not through a 
telephone compauy). These users are anything from novices to veterans who wtsh to 
use the Internet for communication. 

practice, community operators am the technical people at a telephone 
X company. Tney can be expected to use command-line tools to administer the system, 
sc. up supporting gaeways a»d servers, etc. and am trained in doing tins kind of job. 
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!n certain embodiments, end user requirements for a cUent of a user 7 may be as 
follows: 

. 28.8 baud modem connecdon, higher bandwidth for voice depending 
on codec 

. Windows 95 or newer, Windows NT or newer, Windows CE or 

MacOS operating system 
• 16 Mb of memory (4 Mb for Windows CE version) 

The back-end software can run on Windows NT and several of the mainstream 
Unix operating systems^ least Solaris). It can scale well as more money is thrown at 
the server machines (number/speed of processors, amount of memory, amount of 
bandwidth, speed of I/O). 

In certain embodiments, tte client-side application can work Itaongh a SOCKS 
firewall without the system adminismuor needing to do any special setup, and through 
<«,«, fetalis by having the system administrator open a very limited number of ports. 
The client-side application may be a small application. We assume mat the installation 
prog™ for a feature-rich (although not necessarily foil-featured) version may fit on a 
standard floppy disk (1.44 Mb). The application =tu> have a markedly fas. sfcrtup a* 
and its UI can be responsive under all circumstances. 

The overall robnstness of the client-side application may be comparable to otter 
^d-mter software. Specifically, it may: !) Notify the user of mty error messages that 
arereievan.obMmpMntanBuag* Offer the nser to „y m reco^ect antomattcally 
in cases of a lost connection; 2) Notify the user wten the application's back-end 
software has bee- updated, and pom. the user .o a p.ace to download the new version of 

, new versions of itself when it is connecting and finds that the application-, back-end 
has been updated. 
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Therefore, while the present invention is described in relation to preferred 

exemplary of the present invention. Accordingry, it is intended that the invents be 
limited only by the scope of the claims appended hereto. 
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"WHAT IS CLAIMED IS: 

!. Aservernetworkforcnablingrespectiveuserstoe^tab^ 

with other users, the network comprising: 

to and second server clus«s, each cluster including a. least a user urver for 

5 performinguserservicesandanton^^ 

cluster servers in other clusters; 

aid user server in stud first cluster including a roudng service fa a first user 
^igned.osaldfin.cteur.a.tdsaiduserse^tolaidse^ddus^incl.ding. 

routing service for a second user assigned to said second cluster: 

whe^indteftsruaercansendaconnnunicationinviudonmessageor^to 

d.eseconduaerwin^ttoowledgeofte^ofcUen.d^beingudli.edl.vd.e 
^n^^herentth.n^sageorr^ea.iaf^arded^uaeclien.oftosecond 

■a «_# dieter said intra-cluster server in said first cluster, 
user via said user server m said fust cluster, saw ma* ^ 

. . i s\„, t *r and said user server in said second 

said kitra-cluster server in said second cluster, ana saia us 

is cluster; and e .^„^ 
wh=«in»aidrouting service for Ore second use, in the user server of sardsecond 

ehaterforwartsthetoviradonmessa^ 

2. The network of cteim 1, wherein the client of .he second naer compriaeaone 
2o of a personal computer (PC), a mobile phone, and a pager. 

3 TT.enctworiofclaJml.whereineachch^^fucthercc^aeaatleas.one 
connecdon server for connecting the clusrer to r^tive clients of reaped users, and 
each cluster tafcer comprises a daubase from which user servers may access user 

25 information. 

4 The network of claim 3, whereto each cluster includes a plurality of user 
servers.aplurality of totra-ctoster servers, andapluraliry of connection servers. 
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5 mnemorkofcUtal.wheKtoineachcteters.idusct.ervcrp.rfamB 

samscs of other selected users in the network. 

6 Tte^orkotclatal.wb^tteto.^toreg^wHktheflm 

a ri que IDwitmDtheiietwo*;and 

„ ^ioendfteeionCUID)^^" 1 --*"^'^ 0 *^^ 
cluster, such that the UID of the second user constitutes a globally unique ID wtthin the 

network. 

7 T^nr^c* of ctoUwr^ writhe first userUusiu^ac^ 

PC to PC communication, 2) voice chat using PC to PSTN pnone 
3) voice chat using PC to mobile phone communicalion. 

g.Th.nemoArfelaimT.wtermn.whentefimnseriansmgnp^ 
computer (PQ-cUent.mefintandsecondc.ustemen^leme^userandse^ 
J»«— ^catev.monesnou.ermeachofme^tionalfouowmann^*) 
page, using PC ,o PC communication. 5) pages using PC to SMS —cation, and 
6) web conference. 

users, the method comprising the steps of: 

^fientofmefhstusercrearingacommunication session inauscr server of me 



first user; 



WO 00/69140 



PCT/SEOO/00926 



72 



the client of the Hist user encoding an address of the session into an invitation 
message; 

the client of the first user sending the invitation message to a user server of the 
second user, through at least one intermediate server, 

a routing service of the second user on the user server of the second user 
forwarding the invitation message to a client of the second user, and 

the client of the second user accepting the invitation message and connecting to 
the communication session. 

10. The method of claim 9, wherein each of the user server of the first user, the 
user server of the second user, and the at least one intermediate server are all within a 
first cluster of servers, and wherein each of the first and second users are assigned user 
identifiers (UIDs) which include a cluster identifier therein. 

11. The method of claim 9, wherein the communication can be each of PC to 
PC, PC to PSTN phone, and PC to mobile phone, depending upon the client currently 
being used by the second user, and the first user need not know the type of client 
currently being used by the second user at the time the invitation message is sent 

12. The method of claim 9, wherein said step of the client of the first user 
sending the invitation message to a user server of the second user, through at least one 
intermediate server, does not require that the first user or the at least one intermediate 
server know a network address of the second user such as an TP address or a phone 
number, whereby communications may be set up between the first and second users 
while rnaintaining a significant degree of anonymity. 



1 3. A method of establishing a communication session between first and second 
users, the method comprising the steps of: 
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providing at least one server chtfer, and providing a user server for the first user, 
and a user server for the second user, 

a client of the first user sending an invitation message regarding the 
conununication session so the user server for the second user via a connexion serve,; 

fhe user server of the second server determining Whether ro forwmdthe 
tavitadonmessagetoaPC of me secondare*, mottle phone of the second user 
^diogopouanonUnes^ofthePCofmesecondu^^^ 
second server forwaxoingUteinvitadon message ..one.fn.e PC and the mobilephone 

accordingly; and 

to second user receiving the invitation message via the second the PC or mob* 
phone and accepting the invitation. 

14. A network comprising: 
a first cluster and a second cluster, 

each of the first and second clusters including a plurality of user servers in 

commnnicationwithad^ fc 
external user clients, and at least one intra-cluster server for cotnrnunicatinB with other 

clusters of the network; and 

wborein the clusters enableafirs. user connoted to .he first Custer toesmbbsba 
, commumcauonsessionwimaseconJuserofme^ 
knowing an IP address or phone number of the second user. 

15 The network of claim 14, wherein the first user can send an invitation 
message regarding the session to the second user by utilizing a network use, idennfier 

25 (UID) of the second user that includes a cluster identifier. 

16 The network of data 14, when the dusters and ttte network enable the 
catasessirmbemeenmefirstandseconduseratoheeachof:!)^.^ 

using PC to PC commnnieation, 2) voice chat using PC to PSTN phone commumcanon. 
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and 3) voice chat using PC to mobile phone communication, depending upon the clients 
currently in use by the respective users. 

17. A method of togging on to and using a network including a plurality of 
5 cluster servers, the method comprising the steps of: 

providing a client being used by a user, 

providing a cluster including a connection server, at least one user server, a 
mapping function, and a database; 

the client sending a log on request to the connection server; 
10 the connection server checking an entered password for validity; 

the connection server requesting a user server ID from the mapping function, and 
the mapping function selecting a user server in the cluster for the user; 

the connection server setting an online status for the user on the selected user 
server; and 

15 the connection server subscribing to another user's online status so that the user 

can monitor the online status of the another user. 

18. In a network including a plurality of server clusters, a method of a Fust user 
monitoring a status of a second user, the method comprising the steps of: 

20 providing a client for the first user that is in communication with a first 

connection server, 

providing a client for the second user that is in communication with each of a 
second connection server and a first user server, 

when the client for the second user logs on to the network, the second connection 
25 server forwarding status information indicative to the log on to the first user server; 

the first user server forwarding information regarding the status of the second 
user to the first connection server; and 
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the first connection server forwarding information regarding the status of the 
second user 10 the client of the first user so that the first user can monitor the status of 
the second user. 

19. The method of claim 18. farther comprising the step of the second user 
adding second and third users of the network to a blinded list relating to the second us 
so as to prevent the second and third users from monitoring the status of the second 
user. 



10 



20. The method of claim 18, wherein the status of the second user includes 
whether or not the second user is logged on to the network. 
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